Guix

GNU Guix was present this week at the second 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.

On reproducibility

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 work!

At the same time, another group worked on the other thankless task that consists in improving the reproducible build documentation. A big thanks to them!

Testing reproducibility

For a couple of years, Debian has had a 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 integration tool: 77% of the packages are currently reproducible.

Our build farm in Guix doesn't yet have the resources to perform independent rebuilds of packages. We plan to use the shared resources at tests.reproducible-builds.org to achieve that soon. Since last year's summit, our patch 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 packages.

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? Last year, we outlined that reproducible builds are a means to user empowerment. Thus it was great to brainstorm these issues with brilliant minds!

dkg of Debian and ACLU led a couple of sessions on this topic. Tools like guix 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 through the --substitute-urls option. We hope we can extend it to support this “k out of n” policy by the next Reproducible Build Summit!

Bootstrapping

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 when building a complete system “from nothing”. This situation prevents users from knowing what code they’re running, and it makes them vulnerable to trusting trust attacks.

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!

Hacks!

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 a longstanding reproducibility issue in Guile, the Scheme implementation used by Guix—“the shoemaker’s child always goes barefoot”, they say.

Thanks!

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 and respects the user's 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 hackable.

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.