On Sun, 2024-03-31 at 20:12 +0200, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > I would argue there's a danger of getting too tied up in very specific > > technical details of this attack. > > But the fact is: > > What WOULD have stopped this attack: (one or more of:) > * Deleting ALL unit tests in %prep (and then of course not trying to run > them later).
This comes with the huge cost that we no longer have any idea if many things actually work in Fedora. There are much better options here, such as ensuring the package build process *isolates* the test data from the compile process without just *removing* it. but again, this is getting far too tied up in the details of this *one* attack. it's the "everyone has to take their shoes off at the airport forever" mistake: just because the *last* attack involved a binary test file, does not mean the *next* one will. This is also known as preparing for the last war, in military strategy. > * Deleting ALL files automatically generated or imported by autotools in > %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would > NOT have done the right thing here. Delete the files, THEN run autoreconf.) No. This would not have avoided the attack, because it would not have regenerated the malicious file. We have already established that. > * NOT patching OpenSSH downstream to link it against libsystemd against > upstream's recommendation. Again, this is far too tied to the specific attack. I'm not interested, as I said, in Monday morning quarterbacking this specific attack. I'm interested in the question of what are the most immediate and effective ways Fedora can lower its likelihood to be directly targeted in a supply chain attack *in future*. Not the last one. > What WOULD have greatly reduced the impact of this attack: > * NOT enabling updates-testing by default for Branched releases. This would only have helped by coincidence - the coincidence that the compromise was discovered so quickly. Otherwise, we were busy trying to get this update pushed stable as fast as possible, because rwmj wanted that. If the compromise had happened to be caught a few days later, the update would have been pushed stable anyway. Our gating and manual testing processes are not designed to catch security issues, and certainly do not reliably do that job. They did not in this case. So it seems wrong, to me, to suggest we should rely on them to do it in future. Thus I disagree that any possible security benefit gained by doing this would outweigh the substantial disadvantage that we wouldn't get testing of stuff promptly any more. > > What WOULD NOT have stopped this attack: (any or all of:) > * 2FA. GitHub already enforces 2FA. It did NOT stop this attack. Again. I'm not interested in what, with hindsight, might have stopped the attack that already happened. We know for sure that weak authentication processes absolutely are a giant flashing ATTACK HERE neon sign for *future* attackers. > * Any stricter vetting of Fedora contributions. The attack was performed > upstream, NOT in Fedora. See above. > * More distrust of new Fedora contributors. The offending upgrade was > imported by a TRUSTED Fedora contributor. The untrusted new person operated > upstream, NOT in Fedora. See above again. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
