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

Tomas Volf <[email protected]> Sun, 31 Mar 2024 21:03:03 +0200

Newsgroups	gmane.comp.gnu.standards,gmane.comp.sysutils.automake.general
Message-ID	<ZgmzZ4uiS3dq8QWa@ws>

On 2024-03-31 14:50:47 -0400, Eric Gallager wrote:

> > > With a reproducible build system, multiple maintainers can "make dist"
> > > and compare the output to cross-check for erroneous / malicious dist
> > > environments.  Multiple signatures should be harder to compromise,
> > > assuming each is independent and generally trustworthy.
> >
> > This can only work if a package /has/ multiple active maintainers.
>
> 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.

What would be helpful is if `make dist' would guarantee to produce the same
tarball (bit-to-bit) each time it is run, assuming the tooling is the same
version.  Currently I believe that is not the case (at least due to timestamps).
Combined with GNU Guix that would allow simple way to verify that `make dist'
was used, and the resulting artifact not tampered with, even without any central
signing.

Maybe new `dist-reproducible' automake option which would do two things:

1. Try to make things under its control reproducible (e.g.: set timestamps to 0)
2. `make distcheck' would build the archive twice (sequentially), checking that
   the hash matches.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

signature.asc (application/pgp-signature, 833 B)