Followup on Inquiry about regreSSHion postmortem
Rene Malmgren
rene.malmgren at redtoken.ae
Sat Aug 23 00:57:07 AEST 2025
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 at mindrot.org>
Sent: Thursday, August 21, 2025 5:23 PM
To: Rene Malmgren <rene.malmgren at redtoken.ae>
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
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
More information about the openssh-unix-dev
mailing list