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", adding the committers keys inside a
"keyring" branch is required for "guix git authenticate" to work, and
this is what this commit does, but it's not sufficient as an
"introductory commit" is also needed in a given branch to enable to
check the given branch or other branches based on the given branch.
In addition documentation also needs to be written to explain how to
use "guix git authenticate" with GNU Boot, for instance to document
which branches are expected to be authenticated, and the command to
type. This will however be done later on as the command requires the
commit ID of the "introductory commit" mentioned above, and at the
time of writing it isn't pushed yet to any of the GNU Boot branches
that GNU Boot might want to protect.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Denis 'GNUtoo' Carikli
