[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pre-push signature hook error reporting [was Re: [PATCH v6] gnu: pyt

From: Danny Milosavljevic
Subject: Re: pre-push signature hook error reporting [was Re: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.]
Date: Tue, 17 Jan 2017 12:34:28 +0100

Hi Leo,

On Mon, 16 Jan 2017 22:14:14 -0500
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 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]