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

[Eric Gallager]

On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> Russ Allbery wrote:
> > [...]
> >
> > There is extensive ongoing discussion of this on debian-devel.  There's no
> > real consensus in that discussion, but I think one useful principle that's
> > emerged that doesn't disrupt the world *too* much is that the release
> > tarball should differ from the Git tag only in the form of added files.
> >
>
>  From what I understand, the xz backdoor would have passed this check.
> The backdoor dropper was hidden in test data files that /were/ in the
> repository, and required code in the modified build-to-host.m4 to
> activate it.  The m4 files were not checked into the repository, instead
> being added (presumably by running autogen.sh with a rigged local m4
> file collection) while preparing the release.
>
> Someone with a copy of a crocked release tarball should check if
> configure even had the backdoor "as released" or if the attacker was
> /depending/ on distributions to regenerate configure before packaging xz.
>
>
> -- Jacob
>

I would like to clarify that my purpose in starting this thread wasn't
so much to ask, "How could the xz backdoor specifically have been
prevented?" (which seems pretty clearly impossible) but rather, "How
can we use this incident as inspiration for general-purpose
improvements to the GNU Coding Standards and related tools?" In other
words, even if a proposal wouldn't have stopped this particular
attack, I don't think that's a reason not to try it.