// HACKER NEWS — CYBERSECURITY
Bootstrappable Builds: How and Why
Subscriptions are the lifeblood of LWN.net. If you appreciate this
content and would like to see more of it, your subscription will
help to ensure that LWN continues to thrive. Please visit
this page to join up and keep LWN on
the net.
This year's edition of the Free and Open
Source Software Yearly conference, better known as "FOSSY", moved north to the
beautiful (and enormous) campus of the University of British Columbia (UBC)
in Vancouver, Canada from its home for the three previous editions:
Portland, Oregon, in the US. There were many different types of talks at
FOSSY, from deeply technical kernel-track topics, through talks on legal
and community issues, to the "FOSS in Daily Life" talks. In the "Toolchains
and Other Development Tools" track, Timothy Sample gave a presentation
about bootstrappable builds,
which is somewhat less well-known than its cousin, reproducible builds, though LWN
did look at the topic just over two years
ago. In short, a bootstrappable build is one that starts with a tiny
program that can build another slightly larger program, which can build yet
another, and so on, until the entirety of a modern Linux user space is
built from a small seed. Ultimately, it results in code with a
completely understood origin—unlike a typical Linux user space today.
He began by asking attendees whether they had heard of bootstrappable builds
and whether they were generally familiar with the idea; he seemed impressed
that the majority knew the term and that roughly half of the audience knew
more than that. He said that he embarked on the path toward
bootstrappable builds almost ten years ago when he started using GNU Guix (which he pronounced
"geeks"—surprising me). At that time, if you
were using Guix, you were contributing to it, he said with a chuckle. Guix is a
"functional package
manager" that is similar to (and inspired by) Nix.
For both Guix and Nix, all of the software in the system is represented in
a "derivation graph", which describes how to build each of its
programs. There are various inputs required in order to be able to build a
particular program, which are specified in the graph. The way to build
each of the inputs (and, of course, the inputs to the inputs and so on) is
also represented in the graph. "There's hundreds and hundreds of nodes
in modern software, which is terrifyingly complex."
He gave the example of a Python program. It, obviously, requires Python in
order to run, but Python is a C program, so a C compiler is needed.
That C compiler is written in some language, so a compiler for that
language will be needed. And so on. Guix collects all of that into the
graph, which is an object that can be looked at and explored. "So you
start wondering who compiles my compiler's compiler compiler and where does
it stop?"
For a system like Debian, it stops at a C compiler binary that someone has
uploaded to the repositories. For Guix, the original stopping point was
a 250MB statically linked blob of GNU user-space programs. The answer to
where all of that code came from is not entirely clear, of course, which was
unsatisfying to Guix developers. That blob could be built reproducibly,
which is good, Sample said, but does not solve the entire problem.
The basic idea behind bootstrappable builds is to create a system that can
be built without relying on pre-built artifacts. "Can we go from zero
to the modern day without having to just assume the existence of these
already-built-for-us artifacts?" The classic recipe for yogurt
requires some yogurt to start the process, which is like how we normally
build a C compiler today—we start with an existing C compiler binary. You
might think about making sourdough bread with your grandmother's starter
brought over from the old country; "we're basically making C compilers
with Dennis Ritchie's starter carried over from Bell Labs".
It is not just C, of course, as it is true for most languages. It is
something of a point of pride for languag