Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Eric Blake]

[adding in coreutils, for some history]

On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote:
> I was recently reading about the backdoor announced in xz-utils the
> other day, and one of the things that caught my attention was how
> (ab)use of the GNU build system played a role in allowing the backdoor
> to go unnoticed: https://openwall.com/lists/oss-security/2024/03/29/4

I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes.  Automake
gained support for dist-zstd back in 2019 [1], but I'm not sure how
many projects are using it yet.

[1] https://git.savannah.gnu.org/cgit/automake.git/commit/?id=5c466eaf

Furthermore, I was around when GNU Coreutils kicked off the initial
push to support dist-xz (initially named dist-lzma, before a change in
upstream [2]) because of its benefits over over dist-bz2 (compresses
smaller, decompresses faster) [3][4], and even when it ditched
dist-gzip leaving dist-xz as its ONLY release option [5][6], before
needing to be reinstated for bootstrapping Guix [7][8].

[2] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b52a8860
[3] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b75e3b85
[4] https://lists.gnu.org/r/bug-coreutils/2007-10/msg00165.html
[5] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e1c589ec
[6] https://lists.gnu.org/r/coreutils/2011-10/msg00000.html
[7] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=516cdf38
[8] https://lists.gnu.org/r/coreutils/2020-02/msg00042.html

At any rate, it is now obvious (in hindsight) that zstd has a much
larger development team than xz, which may alter the ability of zstd
being backdoored in the same way that xz was, merely by social
engineering of a lone maintainer.

It is also obvious that having GNU distributions available through
only a SINGLE compression format, when that format may be vulnerable,
is a dis-service to users when it is not much harder to provide
tarballs in multiple formats.  Having multiple tarballs as the
recommendation can at least let us automate that each of the tarballs
has the same contents, although it won't make it any more obvious
whether those contents match what was in git (which was how the xz
backdoor got past so many people in the first place).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org