Home Original page

Sourceware mitigating and preventing the next xz-backdoor

Guinevere Larsen blarsen@redhat.com
Tue Apr 2 22:08:59 GMT 2024 
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
More information about the Binutils mailing list