Re: Sourceware mitigating and preventing the next xz-backdoor

Sandra Loosemore
2024-04-02T19:55:02Z

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