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

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Leo,

On Mon, 16 Jan 2017 22:14:14 -0500
Leo Famulari <leo@famulari.name> wrote:

> In Git 2.11.0, it seems that `git verify-commit` can't tell the user
> which commits failed verification:
> 
> https://git.kernel.org/cgit/git/git.git/tree/builtin/verify-commit.c?h=v2.11.0

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). 

> With a warm cache and all the public keys on my machine, checking the
> signature of all 17813 commits on the master branch takes ~40 seconds
...
> Checking the commits one at a time takes ~105 seconds, using something
> like this:
> 
> for commit in $(git rev-list HEAD); do

For minimal improvement (I don't even think it's measureable), try `git rev-list HEAD` (backquotes) - it prevents having to spawn a subshell.

> We could make the hook do something like that. Thoughts? I think the
> performance regression is worth the convenience of knowing why it
> failed.

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).

So I'd say do it your way for now and report it upstream for the future.

Depending on whether we think it will fail more often than not we could also combine it: 
- first check the fast (40 s) path
- if it fails,
  - print "Signature could not be verified to be correct. We are checking which failed..." info message
  - check the slow (105 s) path

Do we think that failures are likely?

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 ?). 

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.