bug#22883: Authenticating a Git checkout

[Leo Famulari]

On Fri, Jun 03, 2016 at 06:12:47PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> So we sign Git commits, and now we want to authenticate Git checkouts.
> There’s a series of bad news.
> 
> First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and
> there’s no way to set it globally.

Since Git already has the git-verify-commit tool, I bet we could
convince the Git project to implement this as a repo configuration
option. Even better if we brought a patch :)

> Second, even if it did, it would be a shallow check: as Mike notes in
> <https://mikegerwitz.com/papers/git-horror-story> with the ‘signchk’
> script, you actually have to traverse the whole commit history and
> authenticate them one by one.  But that’s OK, it runs in presumably less
> than a minute on a repo the size of Guix’s, and we could also stop at
> signed tags to avoid redundant checks.

That doesn't sound so bad.

> Third, as I wrote before¹, relying on the OpenPGP web of trust to
> determine whether a commit is “valid” is inappropriate: what we want to
> know is whether a commit was made by an authorized person, not whether
> it was made by someone who happens to have an OpenPGP key directly or
> indirectly certified.  IOW, we want to know whether the key used to sign
> the commit is among the authorized developer keys.

So, we need some sort of Guix keyring system, right? We'd have to verify
that a signature was made with an authorized key, and then validate the
signature itself? Now it's getting complicated...

> Fourth, there’s inversion of control: ‘git log’ & co. call out to ‘gpg’,
> so if we want to do something different than just ‘gpg --verify’, we
> have to put some other ‘gpg’ script in $PATH.  Blech.
> 
> Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d
> output of ‘gpg’.  Pretty fragile.

According to the man pages gpg(1) and gpg2(1), the value "1" is returned
if a signature check fails, and there are "other error codes for fatal
errors". If these return values are consistent across GPG versions,
maybe they provide enough information for us.

Return values are a lot easier to parse than stdout / stderr, in my
experience.

If we want to go down this path, we should figure out what we'd want to
do with GPG besides `gpg --verify`.

> Sixth, OK, we’ll use libgit2, and write Guile bindings, maybe based on
> the CHICKEN bindings², easy!  Well no, it turns out that libgit2³ has no
> support for signed commits (the ‘signature’ abstraction there has
> nothing to do with OpenPGP signatures.)

That's too bad.