my only contribution to the xz discourse:
absolutely none of the supply chain stuff we're currently doing, including the things i like, would have stopped this. the only things that can stop this are (1) compulsively treating all code as untrusted, and (2) way, way stronger capability checks and restrictions in running systems. (1) is economically infeasible (the world runs on free labor from OSS), and (2) has had only very limited practical success.
(3) reinstate a web of trust; only trust GPG signatures that are well connected in this web of trust through meaningful keysigning
@nik the idea that a PGP signature would have stopped this is, bluntly, unserious. the person in question *was* the legitimate maintainer; there was no a priori reason to distrust them.
(this is before all of the normal observations about the PGP WoT being defunct anyways)
@nik āshouldā is doing a lot of lifting there, and is hoisted on technologies that empirically have *not* done the job well enough. thereās no reason to believe the previous maintainer wouldnāt have shared their key, that the malicious maintainer wouldnāt have been in the strong set, and so forth.
Iām a strong advocate of code signing, and trust distribution is one of the hardest parts; there is no reason to believe that PGPās primitives would have sufficed here.
@segiddins sure, but this was the canonical source! the decision to distribute the tweaked autoconf as a separate package wasnāt the separating factor here IMO; provenance would have only changed things if the backdoor had been inserted at the index or redistribution layer
(I still think we should do things like provenance, but I think this is a great demonstration of their limitations)
I'm sceptical if SLSA actually properly address this? Reproducible builds was removed from the earliest drafts and we are dealing with multiple build processes which forms the distributed artifacts.
If you are defining that `git archive` should match the distributed+signed tarballs I have bad news regarding NPM/pypi.
@yossarian i think that there is room for more people to be involved the distribution process for foss in general. imo, if the project had not been allowed to shrink to a single maintainer, or if there were another community capable of watching it, i think that could have done a lot to help prevent this type of supply chain attack.
but, that does rely on "free labor from OSS", which we still need to address in a more meaningful way. i'm all for getting more people involved and paying them.
What about using sources from version control instead of from released tarballs?
Sure, it's not a general solution to the "malicious committer" problem, but it _is_ a solution to _this_ attack. (Obviously, if we were doing that, the attacker would choose a different attack, though potentially risking a larger chance of discovery.)
@yossarian the only supply chain security thing that I've seen that looks like it might provide any security value is SBOM to at least attempt to document components so that if one of them gets hacked like this you know which parts of your software are actually using that. The problem is that there's no real way to enforce the correctness of the SBOM, so it only helps you if a tiny inner bit is broken like this and not the overall combination, and the combiner makes a genuine attempt to make it complete.
Too many of these efforts still end up running the attackers code and thus don't actually do anything. Wishful thinking, fumbling around in the dark.
I'm still waiting for somebody to show a threat model for any of these efforts and how they mitigate any of the threats therein.
@yossarian how about: for each piece of software, have multiple independent (as in, unlikely to collude) reviewers reading every diff, and flagging anything they don't understand as a potential backdoor?
It's a lite version of (1), since instead of everyone reviewing everything (N*M) we only need a few reviewers for each project (k*M, k < 10).
It'd make every update require a lot more work, but not as much as your (1)
yossarian (1.3.6.1.4.1.55738)
Nik | Klampfradler šøš²
David Cook
noahm
Alexander The 1st
Xarn
Samuel Giddins
Ian McLeod
Morten Linderud
Michael McCune ā®ļø
Matt Palmer
robryk
Reed Mideke
Seth Larson
Eckes 
Billy O'Neal
glyn
Alexander Sosedkin 
Sumana Harihareswara
Wolf480pl
Riley S. Faelan
Paul Cantrell