> On Apr 2, 2024, at 6:08 PM, Guinevere Larsen <blar...@redhat.com> wrote:
>
> 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
I agree that GDB, and for that matter other projects with significant numbers
of contributors, are not nearly as likely to be vulnerable to this sort of
attack. But I worry that xz may not be the only project that's small enough to
be vulnerable, and be security-relevant in not so obvious ways.
One question that comes to mind is whether there has been an effort across the
open source community to identify possible other targets of such attacks.
Contributions elsewhere by the suspect in this case are an obvious concern, but
similar scenarios with different names could also be. That probably should be
an ongoing activity: whenever some external component is used, it would be
worth knowing how it is maintained, and how many eyeballs are involved. Even
if this isn't done by everyone, it seems like a proper precaution for security
sensitive projects.
Another question that comes to mind: I would guess that relevant law
enforcement agencies are already looking into this, but it would seem
appropriate for those closest to the attacked software to reach out explicitly
and assist in any criminal investigations.
paul
