Hi,

On Sun, Mar 31, 2024 at 07:19:41PM -0500, Nicholas Geovanis wrote:
> I would think A Smith's comment here was directed to this interesting bit
> from the report he cited:
> 
> Given the activity over several weeks, the committer is either directly
> involved or there was some quite severe compromise of their
> system. Unfortunately the latter looks like the less likely explanation,
> given
> they communicated on various lists about the "fixes" mentioned above.
> 
> End quote.

I don't really want to go much further into this as the person I
responded to was clearly further upset by what I said, but all I was
suggesting was not getting too worked up about things that are so
far out of one's control.

To bring this sort of thing somewhat more under humanity's control
is going to take some very large scale reworking of how the open
source software supply chain works, possibly even how society works.
It's not something that can be achieved by an end user with a best
practices document or a security checklist. Unless step one on the
list is "give up general purpose computing."

In the xz case the further you go looking for a root cause the wider
the implications are:

Q: Why was there a back door in sshd?
A: Because some malicious code was linked to it.

Q: How did malicious code get linked to it?
A: Its lzma dependency was compromised.

Q: Who compromised the lzma dependency?
A: One of the developers of that project who had full rights to
commit code to it.

Q: Why did a persona that no one knows anything about get full
access rights to a code repository that is linked to openssh?
A: Because they did some work over a period of years that looked
genuine and the single other developer who was overwhelmed with work
decided to give them access based on that

Q: Why did lzma, a dependency of openssh, have a single overwhelmed
developer?
A: Because no one felt the need to pay a team of developers to work
on it or audit work on it.

Society demands that open source developers work, often for free,
and that they merge contributions. If they push back and say they
are unable to due to workload then they are encouraged to seek help
by adding more committers. That's what apparently happened here: the
attacker(s) seemingly counting on the pressure that would exist to
give them rights within the project. It is hammered in to open
source developers over and over:

    Allow others to contribute, or even to take over, if you are too
    busy. It's the right thing to do.

We have now seen proof of what has long been theorised: that the
above way of working is very vulnerable to attackers who are willing
to put in some effort, and that "enough eyes make all bugs shallow"
doesn't hold true unless the process is actually providing those
eyes.

I have no answers on how to fix such a deep-rooted societal problem
but I am not going to start yelling obscenities at people on public
mailing lists because they are wanting to discuss a CVE or whatever.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Reply via email to