I make an assessment based on the facts at hand, and only facts at hand, and I
change my assessment if required, and new information has been gained so I will
write an update. There are several challenges with this, traditionally people
write an RCA, where they go over what happened. I have seen a report on how to
do the exploit, but I have not seen anything that explains how the flags got
removed. This email-thread has given us more information, good.
Now the trouble when you try to distinguish between malice and insanity is that
malice is usually hidden as insanity. My personal rule of thumb is not to
attribute to insanity what could be attributed to malice unless other data point
in that direction. So, a programmer that makes a "mistake" that is way
below their expected performance and then says oh it was a mistake, well usually
you should take a very much closer look.
So no, I did not assume you had a process that was so hazardous, and that you
cared so little for the safety of your non OpenBSD users.
Obviously coming from the outside, you have to make assumptions, that is a
disadvantage. You are also not colored by loyalty to the project or
organization, that is an advantage. Now the way you structure your organization
does not help.
It was your collogue that wanted to have a public discussion, so we are having a
public discussion. I think it's good because these questions need to be
answered (or not answered) so that we know where we stand.
It's generous that you are providing "free" software for us,
unfortunately SAFE provided free software for ByBit and that kind of free cost
ByBit 1.5 BUSD, and yes SSH is used to protect way more in assets than ByBit has
/ had.
No, on a bit of a different topic, do you know why your server, when asked about
a file that looks very similar to a file a regular diff from your repo, easily
posted as a reference in an email.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/log.c.diff?ipk=fF83_JCDCKqCJ85QEwn7jbP5Ag2cF3ZCTZ6QbjGp4RE&r1=1.52&r2=1.53&f=h
Redirects your browser via 301 to https://theannoyingsite.com/
Is this that standard way of handling discussion regarding security in OpenSSH?
/Rene
________________________________
From: Theo de Raadt <deraadt at openbsd.org>
Sent: Wednesday, August 20, 2025 6:09 PM
To: Rene Malmgren <rene.malmgren at redtoken.ae>
Cc: Stuart Henderson <stu at spacehopper.org>; openssh-unix-dev at
mindrot.org <openssh-unix-dev at mindrot.org>
Subject: Re: Followup on Inquiry about regreSSHion postmortem
Rene,
You have already
- decided to not figure out how -portable merges are handled,
- written a long conclusion accusing malice
Now, after that long conclusion you have "questions" ?
I'm pretty sure nothing will change your mind.
> Ok I should be clearer here, yes there are merges, but explain to me how a
merge conflict would remove the two critical flags. I am not talking about
surface here. I am talking about a clear step by step analysis, that shows how
the flags got removed.
>
> /Rene
> ________________________________
> From: Stuart Henderson <stu at spacehopper.org>
> Sent: Wednesday, August 20, 2025 3:07 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 2025/08/20 10:41, Rene Malmgren wrote:
> > Actually, there is no evidence in the available data that such a merge
even has happened
>
> This is simply the way that cross-platform OpenSSH commits are done:
>
> - they are first made to OpenBSD's CVS tree
>
> - then they are later merged to openssh-portable git with an
"upstream:
> XX" comment and OpenBSD-Commit-ID line (with the RCS ID line synced
with
> that from the OpenBSD tree in the commit)
>
> there is plenty of evidence of this, and nothing on the surface unusual
> about this merge commit compared with others
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev