Hey Guix, The source tarball is one release artifact that nobody can reproduce easily. As far as I can see it is usually built by running "make dist" on some merry release team member's machine and contains generated files not in Git. This seems similar (enough) to the gap that xz backdoor made use of.
I'm working on a rough series that builds the release tarball from a single commit with guix time-machine, so anyone can check it. Imagine being able to run something like this to reproduce the release tarball: guix time-machine -q --commit=commit-after-tag-v1.6.0 -- build -e '((@ (gnu ci release) guix-dist-tarball))' One annoying part is how we deal with the ChangeLog, AUTHORS and the commit timestamp. My current approach generates these in a fixed-output derivation that clones the repository (including .git) and runs the release commit's own scripts, that is: - generate a changelog - generate a list of authors - extract a timestamp from the last commit. The content are computed rather than downloaded, which guix usually avoids because tool updates can theoretically change the output. Here I think this drawback is slightly mitigated: - one hash per release, recorded once in the 'guix' package as a (new) package-property, with the tools pinned by that revision. The version and expected hash are recorded by make prepare-release (through update-guix-package.scm). - never substituted (substitutable? #f): rebuilding regenerates the files from Git and fails if there would ever be a hash mismatch. The tarball sources themselves would be substitutable, so this only matters for folks wanting to rebuild the tarball locally. - the stability only works and has always work for the commit after the release tag. What this buys us: - verifiable release tarballs, in some capacity. - the release team member only "primes" the hash locally and pushes the tags and commits; CI can build the actual release tarball by recomputing the output of the FOD (with matching hash, naturally) and building the tarball from there. In a perfect world, they are identical so a signature can be created locally. Where this can bite us: We can have tool-drift, e.g on the assumption that the guix package is still at version 1.6.0 at (much later) commit foobar; guix time-machine -q --commit=foobar -- build -e '((@ (gnu ci release) guix-git-log-files))' ... could lead to the case that the generated files no longer match. This only refer to building a tarball from that commit, not to building guix itself. OTOH, this seems fairly rare as this would mean the output format of git itself has changed. The alternatives that come to my mind are: - a stored/uploaded artifact for just these pieces of "meta-data", which would technically put as back to the start; some blessed pieces of trusted/unverified content. - shipping stub ChangeLog/AUTHORS files (but in that case, why not go for the entire "git archive" route?). Looking forward to your thoughts, especially w.r.t. how I'm holding fixed-output derivations wrong :-) - Jelle
