Re: pre-push signature hook error reporting [was Re: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.]

[Leo Famulari]

On Tue, Jan 17, 2017 at 12:34:28PM +0100, Danny Milosavljevic wrote:
> Leo Famulari <address@hidden> wrote:
> > In Git 2.11.0, it seems that `git verify-commit` can't tell the user
> > which commits failed verification:
> 
> We should report that upstream and add the one line that does tell the
> user which commits failed verification upstream (for example print
> argv[i-1] in line 92). 

Well, it does print the output of `gpg`, but parsing that is
error-prone. I'm sure Git would take a patch that did the right thing,
however.

> Uhhh it's already very slow... so even slower doesn't matter anymore
> (HIG guideline maximum duration is 2 seconds, so we are way off
> anyhow).

Do you notice it in practice? Or do you mean that 40 seconds is already
very slow?

Remember that typical usage does not involve checking every commit, but
only the handful of new commits; this is *much* faster. Checking all
commits is just the benchmark I chose before starting because I wanted
any performance difference to be starkly illustrated.

> Do we think that failures are likely?

Yes, we've seen *bad* signatures pushed to Savannah recently, so I think
it's important for everyone to check their commits before pushing.

> Also, git seems to invoke the gpg executable for each and every
> commit. It would be interesting whether gpg-interface.c
> verify_signed_buffer could be adapted to either invoke gpg once or to
> just use a library instead (gpgme ?). 

Indeed, that would be better.

> Long term we could also cache the checking result - I think that's
> something more difficult in the face of keys that expire. It would
> have to store at least the expiration date, the public key and the
> list of commit hashes that were checked and validated successfully.

Agreed. But this hook is only a convenience tool to prevent mistakes.
We need to revamp `guix pull` to handle this properly.