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
