On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote:
Thanks Arthur, yes, that was *exactly* the point.
I would argue there's a danger of getting too tied up in very specific
technical details of this attack. Yes, it's reasonable to think of ways
to mitigate those specific mechanisms, at least at the appropriate
levels (arguably, most of this is really directly an issue upstream of
us). But it has been - for me - persuasively argued that the specific
technical details were decided based on the wider goals of the attack.
I buy the scenario where the starting point was "how can we poison the
major distributions?" and everything from there derived from that
starting point. xz was picked as the target because of all the specific
technical stuff about systemd and ssh links which people are keen to
dive deep into the details of, but *if that vector hadn't existed the
attacker would just have chosen the next best one*. The specific form
of the attack was then customized to the specific properties of xz,
very cunningly - the whole thing about hiding the payload in binary
test files. But if the attacker had chosen to attack a different
project with different properties, they would have customized their
attack to *that* environment with equal cunning, and it would probably
look quite different.
I think even stepping further back from the technical details is worth
considering. I think xz was picked because it had one maintainer who had
personal issues and low time/desire to continue work, and they were a
good target to be bullied into adding another maintainer. Are there
other critical packages we ship in similar situations?
Worrying *only* about binary blobs in source repos or the specific
details of how systemd opens compression libraries feels a bit narrow,
to me - and especially so when we do it down at the distribution level
where it's not necessarily primarily our responsibility, and I would
argue is definitely not the *lowest* hanging fruit if we take a broader
view of "what should we as a project be doing to raise the difficulty
of supply chain attacks?"
Agreed. I think theres lots of places we should improve, and focusing on
our own backyard first might be wise. But we can also work on the other
parts too!
There are lots of things we _could_ do... we should discuss and consider
what ones make sense in what order. We should just do something because
we can. ;)
Also, a reminder... nothing is ever 'secure'. security is a process. We
consider likelt threats, we try and mitigate them, and we keep doing it.
Things change and we should too.
kevin