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

[Russ Allbery]

Eric Gallager <egall@gwmail.gwu.edu> writes:

> Well, other people besides the maintainers can also run `make dist` and
> `make distcheck`. My idea was to get end-users in the habit of running
> `make distcheck` themselves before installing stuff. And if that's too
> much to ask of end users, I'd also point out that there are multiple
> kinds of maintainer: besides the upstream maintainer, there are also
> usually separate distro maintainers. Even if there's only 1 upstream
> maintainer, as was the case here, I still think that it would be good to
> get distro maintainers in the habit of including `make distcheck` as
> part of their own release process, before they accept updates from
> upstream.

Surely the distro maintainer should just delete all of those files and
regenerate them from already-packaged tools, though?  This is already
partially done by, e.g., Debian and addresses the case of malicious code
embedded in the configure script.

Here it wouldn't have helped because, knowing that the configure script
would be regenerated, the malicious code was embedded in M4 files, but M4
files that come from known external sources could be retrieved from those
sources rather than using the copies inside the package (this is a whole
can of worms, I realize).  And, more relevantly to this specific attack,
distro maintainers can verify that all files in the release tarball are
either missing from Git or exactly match the file in Git with the
appropriate tag.

If there is an upstream Git repository, distro maintainers should probably
just package the signed Git tag, not the release tarball, because it
avoids a whole class of problems like this and ensures that the artifact
that's packaged at least has a Git history and doesn't have changes
injected without version control into the release artifact.

I think the distro problem is in some sense easier.  The problem of the
individual downloader who may not have the tools required to bootstrap
from Git available is much harder.  (But also there aren't the same
advantages to the attacker in compromising those folks, since there isn't
the same mangification of scale as compromising the distro packages.)

> Well, it'd at least make things more difficult for the attacker, even if
> it wouldn't stop them completely.

This is the whole field of security.  Nothing stops attackers completely;
more difficult is the best that one can do.

-- 
Russ Allbery (eagle@eyrie.org)             <https://www.eyrie.org/~eagle/>