automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Russ Allbery
Subject: Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
Date: Mon, 01 Apr 2024 11:04:51 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

"Zack Weinberg" <zack@owlfolio.org> writes:

> I have been thinking about this incident and this thread all weekend and
> have seen a lot of people saying things like "this is more proof that
> tarballs are a thing of the past and everyone should just build straight
> from git".  There are a bunch of reasons why one might disagree with
> this as a blanket statement, but I do think there's a valid point here:
> the malicious xz maintainer *might* have been caught earlier if they had
> committed the build-to-host.m4 modification to xz's VCS.  (Or they might
> not have!  Witness the three (and counting) malicious patches that they
> barefacedly submitted to *other* software and got accepted because the
> malice was subtle enough to pass through code review.)

> It might indeed be worth thinking about ways to minimize the difference
> between the tarball "make dist" produces and the tarball "git archive"
> produces, starting from the same clean git checkout, and also ways to
> identify and audit those differences.

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.
Any files that are present in both Git and in the release tarball should
be byte-for-byte identical.  That, in turn, allows distro tooling to
either use the Git tag and regenerate all the generated files, or start
from the release tarball, remove all the added files, and do the same.
But it still preserves an augmented release tarball for people building
from scratch who may not have all of the necessary tools available.

It's not a panacea (there are no panaceas), but it's less aggressive and
disruptive than some other ideas that have been proposed, and I think it's
mostly best practice already.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]