question about gpg signed commits

[John Arbash Meinel]

Robey Pointer wrote:
> 
> On 16 Jan 2007, at 2:20, Alexander Belchenko wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I'd like to understand gpg signed commits.
>> Working on bzr-config I study gpg-related options.
>> There is bzr command 'sign-my-commits', but no other
>> commands like verify?
>> I don't understood how this infrastructure should work
>> in general and in details. Do I need sign my commits
>> for bzr.dev? For my own bzr-related projects?
>> What means signed repository for another people who
>> want to checkout my signed repository? Does people
>> should mandatory have my open key to working with
>> signed repository?
> 
> I'd like to know more too.  This is a feature I miss from TLA.
> 
> There's a page on the wiki:
> 
>     http://bazaar-vcs.org/BzrGpgSigning
> 
> which says the feature was never quite completed.  Does anyone know if 
> that page is accurate / up to date?
> 
> robey

That page is rather out-of-date.

If you add the line 'create_signatures=always' to ~/.bazaar/bazaar.conf 
under [DEFAULT], bzr will generate a signature for all commits. Which is 
then stored in signatures.knit. And propagated with bzr pull, merge, 
etc. (But not currently with bundles).

I also have a 'signing' plugin[1] which implemented the original 
'sign-my-commits' (which is now a built-in), 'pull-sigs' (which is no 
longer needed because signature.knits automatically pulls all signatures 
not already present). And 'verify-sigs', which will spawn gpg for all of 
the signatures, to check that they are valid.

So the functionality is there, but there are still some limitations 
versus what Arch used to provide.

Signatures are not automatically verified when doing a 
push/pull/merge/etc. I've looked into it from time to time, but the 
python wrappers for gpg were all a little incomplete for me. pygpgme 
should be pretty good, but the last time I tried it, I was having 
problems with segfaults on Mac and general failure on Win32. (This was 
admittedly a long time ago).

So my plugin just falls back to "echo signature | gpg --verify".

At one point 'verify-sigs' could process them in batches, which helped a 
lot with the gpg overhead (when verifying 4000 signatures). But that was 
only when they were text on disk. (It used to verify 50 at a time, and 
if it failed, it would bisect through to find the failing signatures).

So really, to do it correctly in bzr, you should extract all of the 
texts and verify their sha1 sum, and then build up the inventory and 
Testament, and verify that sha1, make sure it matches the value in the 
signature, and then verify that gpg is happy with the signature.

Having to extract all the full texts is one of the blockers, since that 
seems like it would make merge and pull slow. ATM, I wonder if it would 
be small relative to the latency overhead. But certainly merging between 
2 local branches would be slowed down if you had to verify all of the 
revisions.

(To give you an idea of the speed, to verify the 10,947 commits in my 
repository it takes around 15 minutes on my laptop). And of those, only 
4279 are actually signed.

John
=:->


[1] http://bzr.arbash-meinel.com/plugins/signing/

Summary:
Found 10947 revisions, 4279 signed (39.1%) / 6668 unsigned 

4274 valid
    0 invalid
    5 unable to verify
      1 from Bjorn Tillenius <bjorn.tillenius at canonical.com>
      3 from Daniel Silverstone <dsilvers at digital-scurf.org>
      1 from test at canonical.com
    0 invalid testaments (signed text could not be parsed)
    0 mismatched testaments (signed text doesn't match generated text)
  129 mismatched emails (committer email not in gpg signature)

Signers:
         2372 John Arbash Meinel <john at arbash-meinel.com>
          785 Canonical.com Patch Queue Manager<pqm at pqm.ubuntu.com>
          667 Robert Collins <robertc at robertcollins.net>
          207 Andrew Bennetts <andrew.bennetts at canonical.com>
          120 Aaron Bentley <abentley at panoramicfeedback.com>
           78 James Henstridge <james.henstridge at canonical.com>
           17 David Allouche <david.allouche at canonical.com>
            5 James Henstridge <james at jamesh.id.au>
            4 Jelmer Vernooij <jelmer at samba.org>
            4 James Blackwell <jblack at merconline.com>
            4 Brian M. Carlson <sandals at crustytoothpaste.ath.cx>
            4 Brad Crittenden <bac at canonical.com>
            3 Martin Pool <mbp at sourcefrog.net>
            3 Daniel Silverstone <dsilvers at digital-scurf.org>
            2 joe blow <joe at blow.com>
            2 Brad Crittenden <Brad.Crittenden at canonical.com>
            1 test at canonical.com
            1 Bjorn Tillenius <bjorn.tillenius at canonical.com>

The 'mismatched emails' seem to be because Aaron was committing as 
"abentley at panoramicfeedback.com" using the key for 
"aaron.bentley at utoronto.ca".

Well, that and some of Brad Crittenden's commits are "joe at blow.com".

John
=:->