On 4/2/24 16:54, Sandra Loosemore wrote:
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
What likely happened for the maintainer who acted in bad faith was that
they entered the project with bad faith intent from the start - seeing
as they were only involved with the project for 2 years, and there was
much social pressure from fake email accounts for the single maintainer
of XZ to accept help.
While we would obviously like to have more area maintainers and possibly
global maintainers to help spread the load, I don't think any of the
projects listed here are all that susceptible to the same type of social
engineering. For one, getting the same type of blanket approval would be
a much more involved process because we already have a reasonable amount
of people with those privileges, no one is dealing with burnout and
sassy customers saying we aren't doing enough.
Beyond that, we (GDB) are already experimenting with approved-by, and I
think glibc was doing the same. That guarantees at least a second set of
eyes that analyzed and agreed with the patch, I don't think signed-off
would add more than that tag (even if security was not the reason why we
implemented them).
--
Cheers,
Guinevere Larsen
She/Her/Hers
