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
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
