Eric Gallager wrote:
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer <jcb62...@gmail.com> wrote:
Russ Allbery wrote:
[...] 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.
[...]
[...] 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.
I agree that there may be dumber crackers who /would/ get caught by such
a check, but I want to ensure that we do not end up thinking that we
have a solution and the problem is solved and everyone is happy ... and
then we get caught out when it happens again.
I should clarify also that I think that this proposal *is* a good idea,
but we should remain aware that it would not have prevented this incident.
Maneuvering around back to topic, aclocal m4 files are fairly small,
perhaps always carrying all of them that a package uses in the
repository should be considered a good practice? (In other words,
autogen.sh should *not* run autopoint---the files autopoint adds should
be in the repository.) If such a practice were followed, that would
have made checking for altered files between repository and release
effective, or it would have forced the cracker to target the backdoor
more widely and place the altered build-to-host.m4 in the repository,
increasing the probability of discovery.
Wording that as a policy: "All data inputs used to construct the build
scripts for a package shall be stored in the package's repository."
Another related check that /would/ have caught this attempt would be
comparing the aclocal m4 files in a release against their (meta)upstream
sources before building a package. This is something distribution
maintainers could do without cooperation from upstream. If
m4/build-to-host.m4 had been recognized as coming from gnulib and
compared to the copy in gnulib, the nonempty diff would have been
suspicious.
-- Jacob
