That is not true, there is a manager, Theo, he answered, and confirmed some valuable insight into your way of thinking. It really helps to understand the situation better. I also got informed that you are not a lead developer in this project, you are "just the porter". I hope you accept my sincerest apologies; I had no intention to misrepresent you. Never mind the fact that you actually wrote the "feature" both on the OpenBSD side and on the ported side. I also assume that since you have been the person who has been doing the porting over the last 20+ years or so, that you are very familiar with the process. You know full well the hazards of the "#ifdefs", so I assume you knew that if you moved and renamed the functions any modifications on the ported side would be lost, or you could at least claim that you made a mistake. Yet you claim that the process is rock solid and not hazardous. So, witch, is it? Is the process dangerous, and you have been fully aware of it all the time, or is it rock solid and the only time it "failed", it just happened to reintroduce a double zero root exploit into the code, gosh sometime you just run out of luck right, could happen to anybody. And yes, you are totally right, you don't need to explain anything, and I think that the fact that you don't give us plenty of valuable information about what actually happened here. Anyway, the goal of my original post was to make sure everybody was informed about the information we had found, and that people that wanted where able to give us feedback on it. I think that mission has been accomplished, and everybody can draw their conclusions from the dialogue that we have had. I will as I have stated make an update (follow-up) on my original blogpost, this will take a few days, and repost it here. Anybody wanting to comment om my original post is welcome to do so, given they know how to behave. I have a pretty low bar on behavior, but anybodys comment that posts poisoned links will naturally not meet it. I bid you a good day gentlemen. /Rene ________________________________ From: Damien Miller <djm@xxxxxxxxxxx> Sent: Thursday, August 21, 2025 5:23 PM To: Rene Malmgren <rene.malmgren@xxxxxxxxxxx> Cc: openssh-unix-dev@xxxxxxxxxxx <openssh-unix-dev@xxxxxxxxxxx> Subject: Re: Followup on Inquiry about regreSSHion postmortem On Thu, 21 Aug 2025, Rene Malmgren wrote: > We have (sort of) the answer to why the rewrite happened, to introduce > line numbers in error messages. As mentioned, this is one of the things you're still wrong about. > We have yet to see any person here address the elephant in the room, > why where the function renamed and moved to the bottom of the file, > as far as I understand from the logs, marcus signed off on this. Feel > free to ban me for asking the question, or stating that I can't find > any reason other than to hide the re-introduction of CVE-2006-5051. You seem to be laboring under the misapprehension that somebody owes you an explanation or a postmortem. There's no manager here that you can demand to speak to, only some volunteers whom you've just insulted. > If you look at the check-in, in hindsight, it stands out with a +86 / > -96 as line count. The rest of the modifications are usually in single > digits, it's rare that more than 30 lines are modified. A diff hunk line count isn't indicative of anything other than the number of consecutive lines that were changed (this is a frankly weird thing to fixate on). I hate to break it to you but there are far more interesting commits with larger hunk changes than this (hint: try `git log --shortstat` to help find them). Try reviewing those for errors. I predict that you won't pursue this, even though it offers the best opportunity to prove or disprove your thesis. > And the fact > that you guys run a process that is obviously hazardous and are fully > happy with it, is well not ideal. One merge error occasioning a barely exploitable condition in >25 years and many thousands of changes does not an "obviously hazardous" process make. > I am sorry if you don't like the tone, although I would imagine > that you would not like it no matter how it was framed. Because the > assessment that we cannot rule out malicious intent is going to > be there, even if it is delivered with singing and dancing ponies > carrying flowers, and obviously this will be amplified if the scenario > that I assess to be the most probable is actually the correct one. No, you accused me personally of intentionally or incompetently inserting a bug and accused the other OpenSSH developers of laziness based on ... not very much other than misunderstanding and motivated reasoning. You don't get to walk that back. Again, if I'm incompetent and/or malicious and/or the project uses "obviously hazardous processes" then more evidence should be very easy for you to find. Please go find it and let the world know. Again, I predict that this will not happen because reviewing code is hard, tedious work compared to throwing out accusations and calling it "analysis". -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
