Re: authenticating git checkouts

["Ludovic Courtès" <ludo@gnu.org>]

Hi Simon,

Sorry for not noticing your message earlier!

Simon Josefsson via <help-guix@gnu.org> skribis:

> I tried to adopt this approach for the libntlm project, but failed.

Oops!

> x) How about introducing an enforcable file-name convention for the key
> filenames?  While using human readable names like 'alice.key' looks
> nice, it isn't possible to look at content of the filename and determine
> what the filename should be.  The filename doesn't appear to convey any
> important information, so I think it would be better to have it be
> reproducible.  You could use some transliteration of the e-mail address,
> but I think there are corner cases here.  So how about merely using the
> primary PGP fingerprint value?  For me it would be
> B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE.key assuming PGP fingerprints
> are specified as case sensitive.

The convention you propose sounds fine; the one we have in Guix is
convenient too (hash prefix followed by nickname).

I don’t feel a need to enforce a convention, I think it’s fine to let
people do it the way they want.

> x) How about using ASCII armored PGP blobs instead of binary PGP files
> for the *.key files?

Both are accepted.  In the Guix repo, we use ASCII-armored files:

  https://git.savannah.gnu.org/cgit/guix.git/tree/?h=keyring

> While storing binary files in git mostly work these days, I ran into a
> CRLF-related problem for a small binary file in git on Windows lately,
> so it still seems to happen sometimes.  I tried this, but it seems
> 'guix git authenticate' doesn't cope with ASCII armored PGP keys:
>
> Backtrace:
>           12 (primitive-load "/home/jas/.config/guix/current/bin/guix")
> In guix/ui.scm:
>    2312:7 11 (run-guix . _)
>   2275:10 10 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>   1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
>   1747:15  7 (with-exception-handler #<procedure 7f8d006dc7e0 at ic…> …)
> In guix/scripts/git/authenticate.scm:
>    309:10  6 (_)
> In guix/git-authenticate.scm:
>     403:4  5 (authenticate-repository #<git-repository 1ddef20> _ # # …)
> In srfi/srfi-1.scm:
>    460:18  4 (fold #<procedure 7f8d006feb00 at guix/git-authenticat…> …)
> In guix/git-authenticate.scm:
>    255:29  3 (_ _ #<<openpgp-keyring> ids: #<vlist ()> fingerprints:…>)
> In unknown file:
>            2 (open-bytevector-input-port #f #<undefined>)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure open-bytevector-input-port: Wrong type argument in position 1 (expecting bytevector): #f

Clearly error reporting is completely bogus here; looking at the code,
the core issue seems to be that one of these files did not contain valid
radix64, but it could be a CRLF issue leading to that.  Worth reporting
a bug with a reproducer if you can!

> x) How about exporting minimal keys rather than keys with a bunch of
> signatures on?  This makes the key files a bit more reproducible.  The
> downside is that it kills the web-of-trust key authentication process,
> so maybe actually recommend NOT using minimal keys?  I'm mixed on this,
> and this probably needs more discussion.  Maybe minimizing the keys are
> more GDPR-compliant :-)  Doing so also reduces size:

I agree about exporting minimal keys.  This is not enforced, but clearly
there are many benefits to that: GDPR, right, but also performance
(fewer OpenPGP packets to parse).

> jas@kaka:~/src/libntlm$ gpg --export simon@josefsson.org > jas.key
> jas@kaka:~/src/libntlm$ ls -la jas.key 
> -rw-rw-r-- 1 jas jas 105243 maj  9 10:28 jas.key
> jas@kaka:~/src/libntlm$ gpg --export-options export-minimal --export simon@josefsson.org > jas.key

Would you like to send a patch to add this suggestion to the manual?

> x) How about support of non-PGP formats?  You could put PGP keys in a
> sub-directory pgp/foo.key and allow for future expansion as ssh/bar.key
> or x509/baz.key etc.

Back in the day, Git itself supported nothing but OpenPGP.  But you’re
right, it’d be interesting to support SSH keys as well now.  It’s not
very useful for Guix itself, but it would be useful as a general-purpose
tool.

Speaking of which, as mentioned on Mastodon, Finn Landweber implemented
a tool called ‘git-verify’ around the same idea as a proof of concept,
this time using SSH keys:

  https://codeberg.org/flandweber/git-verify

> x) The 'name' field in .guix-authenticate doesn't seem to be necessary
> at all?  Maybe not even suggest including it.

Correct, it’s unused; I find it to be a useful hint but maybe that’s
confusing?

> x) While using s-exp's for .guix-authenticate are fine, I don't think
> this will go down well with the git crowd.  How about a yet another YAML
> format a'la git?  Let's call it ~/.gitauthenticate:
>
> gpg-introduction-commit = a94cffff085b17dd72904d8913411e1e85477e12
> gpg-introduction-keyid = "B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"
> gpg-keyring-branch = gpg-keyring

So this bit of info in .git/config already has this format.  But I guess
you’re talking about ‘.guix-authorizations’ itself, in which case: yes,
I agree that we should standardize on something that works for most, I
had something like JSON in mind.

> x) Running this command:
>
> guix git authenticate 2e6e8027c75942450a0e4ae0f58e876715782cae "B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"
>
> sets up .git/config properly, but running it again with a different git
> commit does not alter .git/config, which was a bit unexpected.  Is this
> intentional?

Yes, but I’m open to suggestions as to what should be done in this case.

> The second invocation exit fine but running 'guix git authenticate'
> again failed.

How did it fail?

> 5) The implementation seems confused by PGP subkeys.  Verifying the
> initial commit after adding .guix-authenticate works fine:

Hmm right, I think you have to mention the subkey ID instead of the
primary key ID, which is confusing.  That’s why we have these comments
with primary key IDs in Guix:

  https://git.savannah.gnu.org/cgit/guix.git/tree/.guix-authorizations

Clearly that’s suboptimal and should be fixed.

> +You can verify the integrity of the git clone by using [guix git
> +authenticate](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html)

s/integrity/authenticity/ :-)

Thanks a lot for trying it out and reporting back!  I see there are bugs
and issues to address, and documentation to improve.  It would be nice
if we could boil them down into bug reports so we can eventually fix
them one by one.

Ludo’.