Security and reproducible-build progress in Guix 0.11

The GNU Guix package-manager project recently released version 0.11, bringing with it support for several hundred new packages, a range of new tools, and some significant progress toward making an entire operating system (OS) installable using reproducible builds.

Guix is a "functional" package manager, built on many of the same ideas found in the Nix package manager. As the Nix site explains it, the functional paradigm means that packages are treated like values in a functional programming language—Haskell in Nix's case, Scheme in Guix's. The functions that build and install packages do so without side effects, so the system can easily offer nice features like atomic transactions, rollbacks, and the ability for individual users to build and install separate copies of a package without fear that they will interfere. Part of making such a system reliable is to ensure that builds are "reproducible"—meaning that two corresponding copies of a binary built on different systems at different times will be bit-for-bit identical.

GuixSD improvements

Our last look at Guix coincided with the 0.9 release in November 2015. That article explored the Guix System Distribution (GuixSD), an installable OS built with Guix packages on top of a base Linux system. At that time, however, GuixSD had to be installed manually, which could be a rather involved process. Since then, one of the most significant changes is that GuixSD can now be installed from a live USB image (a feature that debuted with the 0.10 release in March). That installation process can use binary packages, but one of Guix's calling cards is that source installation for packages is supported as well. Indeed, rebuilding every package from source in a reproducible manner was the original goal. The binary-package installation method offered now is seen as a shortcut for those interested in testing the system out.

In addition to USB installation, GuixSD has gained a security update mechanism. In the past, Guix's adherence to the functional package management paradigm posed a bit of a problem for deploying security updates: updating one package would trigger a rebuild for all dependent packages as well. A simple security patch (not introducing any ABI changes) to one version of a package should, in theory, not alter anything that would cause the dependent packages to build differently. But the functional model of the package manager necessitates the rebuilds anyway, so it does cause an inconvenience for the user.

Guix's solution is referred to as grafting. Essentially, a new package including the security fix is created (for instance, in a bash-fixed package to deploy a patched bash), and the definition of the original package (bash) is updated to point to the new package as a replacement. That "grafts" the new package into the dependency tree and prunes out the unpatched package. Consequently, although the dependency graph has changed, the dependent packages have their dependencies satisfied by the new dependency, so they do not need to be rebuilt. Other package managers that do not attempt to impose functional package-management guarantees do not have to go through such a process, but it was an important missing piece for Guix and GuixSD.

GuixSD has also inched closer to being ready for daily usage with the addition of several new system services. Among the new additions in the 0.11 release are mcron, the Dropbear SSH server, the Dico dictionary service, and a random-number-generation service. Support for RAID arrays using mdadm has also been added, as has device mapper support for LUKS-encrypted partitions.

This is also the first GuixSD release to include support for system-wide tests. Although Guix has long had a robust suite of unit tests and it uses continuous-integration tests on individual packages, in the past it has never had a system-testing framework. The 0.11 release closes that gap. The test framework runs GuixSD in a QEMU virtual machine that is connected to the host system with virtio-serial. There are tests defined for basic functionality, such as successfully starting all of the system services, user account creation, and so forth, as well as a growing set of tests for specific services. Finally, there is a test that starts the GuixSD installer image in VM, then installs and boots GuixSD in a separate VM image.

Packages and reproducibility

Considerable progress has also been made toward making the entire Guix system use reproducible builds. In the 0.10 release, a few core packages (such as glibc, Perl, and Python) were bit-for-bit reproducible. The guix challenge command (which compares binary packages to the output of local builds) was introduced in the 0.9 release, which made systematic testing of build reproducibility possible. Naturally, the testing revealed a lot of work for developers. As of 0.11, steady progress is reported on making all packages build reproducibly, although the project does not yet have a tracking page that shows the status of the effort. That said, Guix is one of several free-software projects working on reproducible builds; those individual projects share their results and have been pushing a number of changes upstream.

Raw numbers are provided for the total number of packages changed, though. The 0.11 release adds 484 new packages and updates 678 existing packages. As a bonus, users can now easily share their own local package builds with the community using the guix publish command. This option spawns an HTTP server (on port 8080) providing the package; other users can fetch and add it to their own system using the Guix tool set.

Incorporating binaries built by others has its share of risks, although the availability of guix challenge lessens the likelihood of surreptitious back doors being inserted. Nevertheless, as Guix has added support for more package origins beyond the local build, it has become necessary to provide tooling for users to manage the complexity. Another addition in 0.11 is an Emacs major mode for browsing, inspecting, and changing the sources of individual packages.

Naturally, there are quite a few smaller changes to be found in the new release as well. For instance, Guix supports multiple user profiles on the same system, and those profiles now follow the freedesktop.org XDG standards (including installation directories, menu specifications, and so on). There have also been many improvements to guix lint and other utilities.

Although Guix has now been in active development for more than three years, it is still a young project—and GuixSD is even younger. Both are still flagged as being not yet ready for daily usage, even though they have accumulated plenty of fans in the free-software community. The progress that the team makes would, no doubt, be impressive for any new "distribution" (if that is even the most appropriate term). The fact that Guix takes a starkly different approach to fundamental package-management tasks makes it all the more interesting to watch.