Have you ever installed an application on a computer, a smartphone or your favourite smart device? Can you trust that it does its job instead of doing the opposite of what it displays on screen or, worse, compromise your data and your private life?
How can you know? You might think “Let’s use free and open source software!” The bad news: it’s far, very far from being enough.
This is a hard and yet very real problem that hits our everyday life constantly. Consider this: the digital pictures of our loved ones, banking operations, the (political?) news feed that we read, our contacts and the communication with our friends and colleagues; all of it happens through applications.
How can we protect ourselves from deceit? How can we guarantee trust in the machines that we use?
First, we need to understand how applications are made.
The assembly line of software
Applications are written in the form of source code, which are specialized human languages made up to give instructions to computers. But the machine cannot understand this source code directly: it must first be compiled into machine code, which are series of operating instructions coded with numbers. The program responsible for translating source code into machine code is called a compiler. The resulting compiled application can then be run by the user.
While the source code is intelligible to humans and offers a pretty high level of transparency of its logic, compiled code is a virtually unreadable sequence of numbers. Moreover, one instruction on source code translates to several coded instructions on machine language. Thus, they are effectively black boxes.
Open source is not enough
We might be tempted to think that free open source software gives us transparency about what’s in the application. While the compiled application we download from the Internet is a black box, we could just compile the source code ourselves and compare the result with the downloaded application, right? If it’s identical, then we are good.
So why is free, open source software not trustworthy then? Because when you compile the source code twice, chances are that you’ll get slightly different black boxes.
So how can you know that the compiled software you’ve downloaded is in fact a proper translation of the source code instead of some modified version of it?
In practice this means that it’s often difficult to reproduce the exact same compiled application that is offered for download.
Notice that it’s enough that merely one 0 or 1 got flipped for the behaviour of the application to change completely. In other words, if two applications are not identical to the bit, everything can happen and all trust vanishes.
This lack of reliability in the compilation of applications comes from the “chaos” in the machine environment: slightly different software used for compilation (e.g. different versions), different hardware, different date… The slightest difference in the compilation environment is susceptible to flip a bit.
This is called the reproduciblity problem.
Software is made with software
The compiler is also an application that must be compiled, by another compiler, from some source code. The same applies to this other compiler, and so on. It seems to be a chicken and egg problem: can we ever trust any compiler then?
It is actually possible: if we go up the chain of compilers far enough, we reach a level where we have a trivial “machine level” compiler that can build a simple compiler from source. This machine-readable file is small enough that it is no longer a black box and can be inspected by humans. The simpler compiler can in turn build a more complex compiler, etc., until we get today’s compilers.
This is called the bootstrappability problem.
Trust all the way
To sum up, we need the following properties in order to be able to trust computer software:
- Free and open source software.
This is only useful if the entire software running on your machine obeys these principles. A single black box on your machine can wreck havoc. In other words, the entire operating system itself must be free and open source software, reproducible and bootstrappable.
This is precisely GNU Guix’ stated goal: Offer a strong guarantee of reliability and trust.
- Reliability: It just works, and more importantly, it will always work. No more unexpected, random behaviour; no more “software erosion.”
- Trust: Work is in progress to fully bootstrap the software assembly line, which means everything will soon be fully transparent..
What’s even more interesting with Guix is the that this novel approach to operating systems gives it great usability benefits:
- Unbreakable system and time travel: Have you ever updated a system only to restart it broken or less functional? (Say there was a power cut during the upgrade.) With Guix you keep a history of all previous states of the system, even when you change the configuration manually. If something breaks, you can always go back in time. No more fear of updates or tinkering around with the settings!
- Multiple versions: Sometimes you’ll need an older version of a program (for instance to support an old format or a feature that’s gone in a newer version). Guix allows to install multiple versions of the same program in parallel.
Can everyone use Guix?
Guix is currently (January 2020) actively developed by a community of programmers from all over the world. It is stable and can be used in a number of settings, from laptop and desktop computers to servers and scientific computing.
More work needs to be done in terms of accessibility and ease of use so that the less technically-minded among us can also enjoy Guix some day. Then, hopefully, we will find Guix preinstalled on computers, ready for everyone to use.
If you’d like to contribute in some way, feel free to reach out to us!
- André Nunes Batista
- Sherab Kelsang
- https://guix.gnu.org: The home page of GNU Guix with blog articles, documentation, videos and more.
- https://nixos.org/: The other operating system that targets similar goals. Nix was an inspiration for Guix.
- https://en.wikipedia.org/wiki/Backdoor_(computing)#Compilerbackdoors: Compilers can be malicious and create malicious compilers in turn. This is commonly known as the “Thompson attack,” as first mentioned in the speech “Reflections on Trusting Trust” by Ken Thompson.
- https://www.quora.com/What-is-a-coders-worst-nightmare/answer/Mick-Stute?srid=RBKZ&share=1: The story of an actual implementation of the “Thompson attack.”
- https://reproducible-builds.org/: Technical information on reproducibility.
- https://bootstrappable.org/: Technical information on bootstrappability.
- https://www.gnu.org/software/mes/: GNU Mes is a project that aims at bootstrapping the main compilers until stage0.
- https://savannah.nongnu.org/projects/stage0: The “machine-level” compiler that both readable by machines and humans.