GNU Guix was present this week at
Reproducible Build Summit in Berlin. Three of us were there.
We happily joined a dozen of other free software projects, mostly
distros, to discuss cross-cutting reproducibility issues going from
outreach to hacking on a specific piece of software. This attempts
to summarize important points that were discussed in some of the
sessions we attended, and how Guix fits into that.
What does it mean for a build process to be reproducible?
That sounded obvious to many attendants, but experience has shown
that many outside of the community needed clarifications. A group
led by Ed Maste of FreeBSD worked hard to come up with a definition
that is both concise, accurate, and generic. Impressive and useful
At the same time, another group worked on the other thankless task
that consists in
reproducible build documentation. A big thanks to them!
For a couple of years, Debian has had
dashboard that shows the progress that has been made. The
result is impressive: 92% of its source packages are now bit-for-bit
reproducible! During the meeting, Eelco Dolstra reported first
results for NixOS, obtained thanks to an extension to
the Hydra continuous
of the packages are currently reproducible.
Our build farm in Guix doesn&apost yet have the resources to perform
independent rebuilds of packages. We plan to use the shared
to achieve that soon. Since last year&aposs summit,
submission guidelines require submitters to check for
reproducibility issues using guix build --rounds=N.
This has already allowed us to fix lots of reproducibility issues in
User-facing interfaces to reproducible builds
Reproducible builds should allow users to verify builds, and
distributors to no longer be single points of failure. But how
can we actually empower users with reproducible builds?
outlined that reproducible builds are a means to user
empowerment. Thus it was great to brainstorm these issues with
dkg of Debian and ACLU led a couple of sessions on this topic.
challenge are one way to help users check whether their
binaries are trustworthy, provided independent package builds are
available. Some suggested that this could be used as an input for a
more general kind of “system health” monitoring tool.
A large part of the discussion then focused on policies
that users could select. For example, assuming several independent
organizations provide binaries for a given distro, users could
disallow installation of binaries for which providers disagree on
the output. Worded like this, the policy could easily lead to
denial of service should one of the providers be unavailable. A
refinement of this policy is to install only packages for
which k out of n known builders “agree” on what
the package contents are.
Guix currently allows users to specify multiple binary providers
the --substitute-urls option.
We hope we can extend it to support this “k out of n”
policy by the next Reproducible Build Summit!
The Summit focuses on reproducible builds, but
unfortunately, there are more and more situations where software is
not built from source. In most cases, this is due
to bootstrapping issues: a compiler is written in the
language it compiles, and thus distributors have no choice but to
start from an opaque pre-built binary provided by upstream. The
problem also comes up
a complete system “from nothing”. This situation prevents users
from knowing what code they’re running, and it makes them vulnerable
In Guix, the debate came up every time we added one of these
self-hosted compilers—Rust, OCaml, GHC, etc. This is not a
comfortable situation. We led sessions on this topic with two
goals: to try and make a specific package “bootstrappable”, and to
raise awareness and come up with guidelines for compiler and tool
writers. Together with other hackers, we drafted a manifesto that
we hope to publish soon. Stay tuned!
During the hacking sessions, while Ricardo was busy working on the
bootstrapping manifesto, John together with Pierre Pronchery of NetBSD
tackled gettext reproducibility issues, and
Ludovic picked up the work of others on fixing
reproducibility issue in Guile, the Scheme implementation used
by Guix—“the shoemaker’s child always goes barefoot”, they say.
We would like to thank the sponsors who helped make the Reproducible
Build Summit possible: Debian, Google, Linux Foundation, and Open
Tech Fund. Special thanks to Beatrice and Gunner of Aspiration and
to Holger of Debian for the perfect organization, and for the
productive and friendly atmosphere they created!
About GNU Guix
GNU Guix is a
transactional package manager for the GNU system. The Guix System
Distribution or GuixSD is an advanced distribution of the GNU system
that relies on GNU Guix
the user&aposs freedom.
In addition to standard package
management features, Guix supports transactional upgrades and
roll-backs, unprivileged package management, per-user profiles, and
garbage collection. Guix uses low-level mechanisms from the Nix
package manager, except that packages are defined as
native Guile modules,
using extensions to the Scheme
language. GuixSD offers a declarative approach to operating system
configuration management, and is highly customizable and
GuixSD can be used on an i686 or x86_64 machine. It is also possible
to use Guix on top of an already installed GNU/Linux system, including
on mips64el and armv7.