Re: Sourceware mitigating and preventing the next xz-backdoor

[Sandra Loosemore <sloosemore@baylibre.com>]

On 4/1/24 09:06, Mark Wielaard wrote:
> A big thanks to everybody working this long Easter weekend who helped
> analyze the xz-backdoor and making sure the impact on Sourceware and
> the hosted projects was minimal.
> 
> This email isn't about the xz-backdoor itself. Do see Sam James FAQ
> https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
> (Sorry for the github link, but this one does seem viewable without
> proprietary javascript)
> 
> We should discuss what we have been doing and should do more to
> mitigate and prevent the next xz-backdoor. There are a couple of
> Sourceware services that can help with that.
> 
> TLDR;
> - Replicatable isolated container/VMs are nice, we want more.
> - autoregen buildbots, it should be transparent (and automated) how to
>    regenerate build/source files.
> - Automate (snapshot) releases tarballs.
> - Reproducible releases (from git).
> 
> [snip]

While I appreciate the effort to harden the Sourceware infrastructure 
against malicious attacks and want to join in on thanking everyone who 
helped analyze this issue, to me it seems like the much bigger problem 
is that XZ had a maintainer who appears to have acted in bad faith.  Are 
the development processes used by the GNU toolchain components robust 
enough to cope with deliberate sabotage of the code base?  Do we have 
enough eyes available to ensure that every commit, even those by 
designated maintainers, is vetted by someone else?  Do we to harden our 
process, too, to require all patches to be signed off by someone else 
before committing?

-Sandra