On Sun, Mar 31, 2024 at 3:54 PM Russ Allbery <ea...@eyrie.org> wrote: > > Eric Gallager <eg...@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 (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
