bug#22883: Authenticating a Git checkout

[Justus Winter]

Ludovic Courtès <address@hidden> writes:

> At this stage, ‘make authenticate’ uses the pure-Scheme implementation
> (based on Göran Weinholt’s code, heavily modified).  It can authenticate
> 14K+ commits in ~20s instead of 4m20s on my laptop, which is really
> nice.

Neat :)

> Signature verification in (guix openpgp) does just that: signature
> verification.  It does not validate signature and key metadata, in
> particular expiration date.  I guess it should at least error out when a
> signature creation time is newer than its key expiration time.

Indeed.  I skimmed both the original and the adapted code, and it
notably does no attempt to canonicalize the certificates in the keyring
(i.e. checking binding signatures, lifetimes, revocations, (sub)key
flags...).  While that is a bit dangerous, it is okay for a point
solution for Guix, provided that this is properly documented and
communicated.

One can forgo canonicalization if one assumes that the keyring is
curated, and one has a good-list of (sub)keys fingerprints that are
allowed to create signatures.  Reading git-authentiate.scm that does
seem to be the case.

(I bet that certificate canonicalization is the major reason why calling
out to gpgv is so slow:  it does that every time, and it involves
signature verification, which is slow (yes, I'm looking at you, RSA).)

> It should also reject SHA1 signatures, at least optionally (I haven’t
> checked whether our Git history has any of these).

I believe it should.  For reference, we reject SHA1 signatures for
signatures created since 2013.

> Next steps:
>
>   • Clean up the (guix openpgp) API a bit, for instance by using proper
>     SRFI-35 error conditions.  Perhaps handle v5 packets too.

Don't bother with v5 packets for now.  The RFC is nowhere near
completion, and even if it is one day, it will be quite some time until
you see these packets in the wild.


All the best,
Justus

signature.asc
Description: PGP signature