Hello Guix!

It’s high time for us to provide a means to authenticate Git checkouts.
It’s not clear what the perfect solution will be, so in the meantime I
think we need to have reasonable milestones that incrementally improve
the situation.

To begin with, I propose the attached script: when given a commit range,
it authenticates each commit, meaning that it ensures commits have a
valid signature and that that signature was made by one of the
authorized keys.  Sample session:

--8<---------------cut here---------------start------------->8---
$ time ./pre-inst-env guile -e git-authenticate build-aux/git-authenticate.scm d68de958b60426798ed62797ff7c96c327a672ac 099ce5d4901706dc2c5be888a5c8cbf8fcd0d576
Authenticating d68de95 to 099ce5d (7938 commits)...
Signing statistics:
  BCA689B636553801C3C62150197A5888235FACAC       1454
  3CE464558A84FDC69DB40CFB090B11993D9AEBB5       1025
  BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA        941

[...]

real	2m21.272s
user	1m38.741s
sys	0m59.546s
--8<---------------cut here---------------end--------------->8---

Limitations:

  1. People (developers) have to run it manually, there’s no suitable
     Git hook; ‘guix pull’ doesn’t run it.

  2. The list of authorized keys is hard-coded.

  3. It’s relatively slow (but faster than a shell script).

  4. It lazily populates a keyring (under
     ~/.config/guix/keyrings/channels/guix.kbx) by fetching keys from
     key servers, which may or may not have the keys.

  5. It doesn’t address roll-back attacks and other attacks described in
     <https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias>.

  6. It doesn’t memorize which commits have already been verified.

  7. I haven’t checked whether the hard-coded ‘%committers’ lists works
     for commits before v1.0.1—help welcome!

It should be possible to address #2 by adding the list in the repo
itself, though we’d need to check the cost of accessing that list at
every commit.

#3 can probably be addressed by using a Scheme implementation of the
OpenPGP bits we need, such as that of Industria.

#4 can be addressed by storing the keys in the repo itself, either as
files directly or with a trick like
<https://365git.tumblr.com/post/2813251228/adding-a-gpg-public-key-to-a-repository>.

#6 could be addressed by storing Git notes maybe.

#5 is hard IMO, but it’s one of the things we discussed at the R-B
summit, so there’s hope.

I’d like to commit this script under build-aux/ as a first step.

Thoughts?

Thanks,
Ludo’.

PS: See <https://issues.guix.gnu.org/issue/22883> for context.