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