Sourceware mitigating and preventing the next xz-backdoor

[Mark Wielaard]

Hi,

On Tue, Apr 02, 2024 at 07:08:59PM -0300, Guinevere Larsen wrote:
> On 4/2/24 16:54, Sandra Loosemore wrote:
> >On 4/1/24 09:06, Mark Wielaard wrote:
> >>
> >>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?
>
> [...]
> 
> 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).

Yes, I agree having a policy of requiring all patches to be reviewed
and showing that by adding tags like Approved-By is a good thing. And
I think the gdb approach is simple and sane:
https://sourceware.org/gdb/wiki/ContributionChecklist#Receiving_positive_reviews

Like all the other suggestions it wouldn't really prevent all
attacks. But you shouldn't do this just for "security" anyway. I would
even say that if you do something only to get a security "badge" then
you are doing it wrong.

The "hardening" projects above were also not just for "security" but
also because they are good and sane things to do anyway. We try to put
everything in separate containters or isolated VMs also because that
just makes maintenance easier, helps migrating workloads, shows users
how setup the services locally. Having automated reproducible
snapshots and releases also helps having clear procedures for
regenerating files, makes (pre-commit) CI more reliable, helps
bootstrappability.

The reason I only listed the above four "hardening" steps was because
they have clear Sourceware infrastructure services that could help and
that we are working on already anyway. Having a Reviewed-By policy is
really "just" a project policy that doesn't require any infrastructure
help. Although we could have a git push hook that makes it mandatory.

You could however go further and use signed commits or pushes, Both of
which Sourceware infrastructue supports:
https://inbox.sourceware.org/ZJ3Tihvu6GbOb8%2FR@elastic.org/

Or if the project wants to we could migrate them to gitolite and/or
install strict hooks for who may push to (release) branches.

Just let us know. The Sourceware Infrastructure is ready, but most of
these issues are really project policy.

Cheers,

Mark