On Sun, 2024-03-31 at 13:35 +0200, Arthur Bols wrote: > On 31/03/2024 13:03, Kevin Kofler via devel wrote: > > This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for > > contributors for a while, starting with "important" projects, then getting > > stricter and stricter. It has done absolutely nothing to stop this attack. > > How could it, when the backdoor was apparently introduced by the authorized > > maintainer? (Or if not, the attacker must have had access to their 2FA > > secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON > > US! And especially DO NOT abuse this incident as an excuse to force 2FA down > > our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being > > repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! > > 2FA for Fedora packagers doesn't solve *this* issue, but that wasn't > Adam's point. What Adam is saying is that we're in danger of focusing > too much on a specific issue while we should spent our time and energy > on the general security aspect of Fedora. 2FA isn't nonsense, it > strengthens security by a lot. 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. 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?" -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net -- _______________________________________________ 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
