gnuboot-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v3 1/1] Add .guix-authorizations file for "guix git authenticate"


From: Denis 'GNUtoo' Carikli
Subject: [PATCH v3 1/1] Add .guix-authorizations file for "guix git authenticate".
Date: Sun, 13 Oct 2024 16:40:00 +0200

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
4a82cc82d207a9eb4458e5f8e8ab0dd2d9de127f ("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>
---
 .guix-authorizations | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 .guix-authorizations

diff --git a/.guix-authorizations b/.guix-authorizations
new file mode 100644
index 0000000..3f0efec
--- /dev/null
+++ b/.guix-authorizations
@@ -0,0 +1,7 @@
+(authorizations
+ (version 0)               ;current file format version
+
+ (("FB31 DBA3 AB8D B76A 4157  329F 7651 568F 8037 4459"
+   (name "GNUtoo"))
+  ("E23C 26A5 DEEE C5FA 9CDD  D57A 57BC 26A3 6871 16F6"
+   (name "neox"))))
-- 
2.46.0




reply via email to

[Prev in Thread] Current Thread [Next in Thread]