My main key fingerprint was used inside .guix-authorizations, but all
my commits are signed with a subkey and 'guix git authenticate' only
works if we put my subkey inside .guix-authorizations.
I also remember that at some point I had verified that 'guix git
authenticate' worked for my key, so I probably lost the changes that
made it work (using my subkey) at some point while moving to another
repository to do tests that don't interfere with my main work on
GNU Boot.
This was broken from the start in the commit
bf2b91df54aa71ecbfab891d32000ad2d6af6093("Add .guix-authorizations
file for "guix git authenticate"").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
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
4a82cc82d2 ("Add GNU Boot committer keys
for "guix git authenticate".").
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 this would require the commit ID
of this commit, and it's impossible to forge a commit whose ID is also
in the commit message or changes without breaking the security of git
or without writing complex code that retrieves the commit ID
dynamically.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Denis 'GNUtoo' Carikli
