Followup on Inquiry about regreSSHion postmortem

Damien Miller djm at mindrot.org
Thu Aug 21 23:23:01 AEST 2025


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