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

[Eric Gallager]

On Sun, Mar 31, 2024 at 3:54 PM Russ Allbery <eagle@eyrie.org> wrote:
>
> 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).

So, `aclocal` has a flag to control this behavior: specifically, its
`--install` flag. Right now I don't see `aclocal` mentioned in the GNU
Coding Standards at all. Should they be updated to include a
recommendation as to whether it's better to put `--install` in
`ACLOCAL_AMFLAGS` or not? Or would such a recommendation be a better
fit for the `automake` manual (since that's where `aclocal` comes
from)?

> 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/>