GNUBoot/gnuboot
GNUBoot
/
gnuboot
mirror of https://git.savannah.gnu.org/git/gnuboot.git
2
1
Fork 0
Code Issues Releases Activity
gnuboot/.guix-authorizations

8 lines
225 B
Plaintext
Raw Normal View History

Add .guix-authorizations file for "guix git authenticate". 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> Acked-by: Adrien Bourmault <neox@gnu.org>
2024-10-13 16:40:00 +02:00
(authorizations
(version 0) ;current file format version
Fix .guix-authorizations for Denis 'GNUtoo' Carikli. 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>
2024-10-14 15:30:58 +02:00
(("782F 9DDB E36B A7F3 D4DE 4906 5F5D FCC1 4177 E263"
Add .guix-authorizations file for "guix git authenticate". 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> Acked-by: Adrien Bourmault <neox@gnu.org>
2024-10-13 16:40:00 +02:00
(name "GNUtoo"))
("E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6"
(name "neox"))))