Denis 'GNUtoo' Carikli
bf2b91df54
Since GNU Boot currently lacks reproducible builds, building GNU Boot
from source can be a good idea.
However currently the only supported and documented way of build GNU
Boot requires to download GNU Boot from git (signed tarballs and/or
git bundles are completely untested and not supported yet), and while
the commits are signed with GPG, there is no easy way to check the
integrity and authenticity of the source code.
To do the check a person or a program would need to get the keys of
the two current maintainers and somehow do the check with git
directly.
Using "guix git authenticate" instead enables to do that more easily:
only one command is needed, and the command will more likely keep
working over time than the method mentioned above.
Guix is also improving it over time: for instance it recently added
automatic checks through git hooks (through the guix commit
8d1d98a3aa3448b9d983e4bd64243a938b96e8ab ("git authenticate: Install
pre-push and post-checkout hooks.").
Since:
- the "guix git authenticate" command was introduced in the Guix
commit a98712785e0b042a290420fd74e5a4a5da4fc68f ("Add 'guix git
authenticate'."), between Guix 1.1.0 and Guix 1.2.0
- at the time of writing only the following free distributions have
a guix package: Guix, Parabola, PureOS 10 (byzantium), and that
PureOS 10 has the oldest Guix version (1.2.0)
there is probably no need to update Guix in most cases. This
facilitates checking even more, especially because Guix is already
required to build GNU Boot.
In contrast if we look at an alternative called "in-toto"
(https://in-toto.io/), it's not packaged in Dragora, Guix, and
Hyperbola but it's packaged in Parabola, PureOS (10), Trisquel (10,
11), and in very few nonfree distros
(https://repology.org/project/in-toto/versions).
And even if in-toto was packaged in Guix, it would take way longer to
get it through Guix as it's not in Guix 1.4.0 and we would then need
to download a complete set of dependencies just for in-toto as
backporting it would break the chain of trust.
And in-toto is also meant to authenticate complete "supply-chains" and
so it manages well the distribution of responsibilities in an
organization where the people responsible for building releases and
writing the code are different for instance, and so it can easily
manage the signature and authorization of git tags, but I found no
example for signing each git commit in a given branch (see
https://github.com/in-toto/demo and
https://medium.com/synechron/securing-your-software-supply-chain-with-in-toto-5b90a6423c88
for more details).
And here it would be problematic to only secure tagged commits as it
would in practice prevent users that care about source code integrity
from building commits that are not tagged without reviewing them
manually again and again. And doing work to secure all commits would
probably be time consuming and/or error prone, and in contrast 'guix
git authenticate' is readily available.
In addition, at the time of writing current or potential users and/or
contributors to GNU Boot are probably more familiar with "guix git
authenticate" than "in-toto" because the former is mentioned in the
Guix manual and its use is documented on the Guix blog
(https://guix.gnu.org/en/blog/2024/authenticate-your-git-checkouts/)
and in conferences.
In contrast in-toto is also promoted in conference(s) and it's already
used by projects like GitLab, Jenkins, rebuilderd, etc
(https://github.com/in-toto/friends) but then no GNU projects or FSDG
distributions seem to use in-toto or to promote it, so fewer current
or potential GNU Boot users and/or contributors are aware of it.
This also means that learning to use "guix git authenticate" is more
likely to be useful for GNU Boot users and/or contributors than
learning "in-toto".
To use "guix git authenticate", we need to add a .guix-authorizations
file in the branches we want to be able to authenticate, and we do
that in this commit, but this is not sufficient as we also need to add
the committers keys inside a "keyring" branch in the same repository.
The keyring was already added in the commit
|
||
|---|---|---|
| contrib | ||
| resources | ||
| tests | ||
| website | ||
| .gitignore | ||
| .guix-authorizations | ||
| COPYING | ||
| Makefile.am | ||
| README.md | ||
| autogen.sh | ||
| build | ||
| configure.ac | ||
| download | ||
| modify | ||
| projectname | ||
| update | ||
README.md
GNU Boot
This software is part of the GNU Project.
To load an operating system, computers need to be able to access storage devices (like an HDD or SSD) where the operating system is installed. They need RAM to work to load part of the operating system in RAM. Users also expect the display and keyboard to work before the operating system is loaded.
But on most computers, software is needed to initialize the RAM, the storage devices, the graphic card, to load the operating system, and give some information to the operating system on what hardware it is running on.
Because of that computers usually require boot software that is bundled in the computer. It is usually found on a very small storage chip that is inside the mainboard. That software is specific to a given computer.
Unfortunately that software is usually nonfree and GNU boot aims to replace that with 100% free software.
Like with other type of software, the fact that it is nonfree has real impacts. For instance this software often continues to run once the operating system is loaded and as it loads the operating system it can also modify it.
So having a nonfree boot software make it impossible for users to really trust their computers. Another common issue is that some BIOS/UEFI add restrictions to prevent users from replacing the WiFi card for instance. There are many more issues but listing them all here would make this description too long.
To replace nonfree boot software, GNU boot reuses various software projects (like Coreboot, U-boot, GRUB, SeaBIOS, etc), configure and build them to produce an image that can be installed to replace the nonfree boot software for specific computers.
Users can also do all that without GNU Boot but that tend to be complicated. Having a free software project that does all that enable people to collaborate on making sure that computers boot fine regardless of the upstream project status, for instance by making binary releases and collaborating to test them.
In addition GNU boot also comes with extensive documentation to make it as easy as possible to install GNU Boot and to empower users to modify the way their computer boot.
Since not all the project it reuses are 100% free software it also removes all the nonfree software found in them along the way and will also make the scripts and/or data that does that reusable for distributions or users that want to build their own free boot software without reusing the GNU Boot configuration or build system.
Not a coreboot fork!
GNU Boot is not a fork of coreboot, but more a boot firmware distribution including a modified version of coreboot, and other software like SeaBIOS, GRUB or u-boot.
Coreboot is not entirely free software as it includes binary blobs in it for some platforms. What GNU Boot does is download several revisions of coreboot, for different boards, and de-blob those coreboot revisions. This is done using the linux-libre deblob scripts, to find binary blobs in coreboot.
All new coreboot development should be done in coreboot (upstream), not GNU Boot. For example, if you wanted to add a new board to GNU Boot, you should add it to coreboot first. GNU Boot would then receive your code at a later date, when it updates itself.
The deblobbed coreboot tree used in GNU Boot is referred to as coreboot-libre, to distinguish it as a component of GNU Boot.
How this project came to exist
We believe computer users deserve to control all the software they run. This belief is the key principle of the Free Software Movement, and was the motive for developing the GNU operating system and starting the Free Software Foundation. We believe computer user freedom is a crucial human rights.
Unfortunately, such a muddle happened last year with a boot program that was free software and was called Libreboot: the development team added nonfree code to it, but continued to refer to it misleadingly as “Libreboot”.
Libreboot was first released in 2013. It has been widely recommended in the free software community for the last nine years. In November 2022, “Libreboot” began to include non-libre code. We have made repeated efforts to continue collaboration with those developers to help their version of Libreboot remain libre, but that was not successful.
Now we’ve stepped forward to stand up for freedom, ours and that of the wider community, by maintaining our own version – a genuinely libre boot distribution: GNU Boot.
LICENSE FOR THIS README: GNU Free Documentation License 1.3 as published by the Free Software Foundation, with no invariant sections, no front cover texts and no back cover texts. If you wish it, you may use a later version of the GNU Free Documentation License as published by the Free Software Foundation.
Copy of the GNU Free Documentation License v1.3 here: https://www.gnu.org/licenses/fdl-1.3.en.html
Info about Free Software Foundation: https://www.fsf.org/