bzr.dev missing signatures

[John A Meinel]

Martin Pool wrote:
> On  8 May 2006, John A Meinel <john at arbash-meinel.com> wrote:
> 
>> I think I would prefer to hold off on that until we actually have
>> signature verification. Using the indexes you can easily figure out what
>> needs to be merged, and then you can pull them, verify them, and save them.
>>
>> That was part of why I updated my 'signing' plugin. Because I realized
>> that just checking the signature wasn't enough. You could have a
>> signature of bogus text.
> 
> Do you think we could merge the signing plugin into bzr core?

Well, neither one is fully tested. And 'verify-sigs' has some
expectations that the gpg_command() supports --verify rather than just
--clearsign. Which hasn't been part of the spec. I really don't know if
it would work with anything other than plain 'gpg', since that is all I
have installed to test with.

> 
>> We also need to decide whether we want to support signing commits that
>> don't match on email address. (Whether because john at arbash-meinel.com is
>> signing commits for john at johnmeinel.com, or because I'm approving
>> abentley at utoronto.ca commits).
> 
> In the first place I would say that it should match the revision's
> author address.  As Jan pointed out you can add as many addresses to a
> key as you like.  If it doesn't already, the signing plugin could use
> 'gpg -u' to make them match.
> 
> Signing someone else's commits, to say "I approve of this commit by
> Aaron" is interesting but secondary.  You can get something like it at
> the moment by signing a merge of aaron's revision into your own branch.
> 

That is where I ended up. We can allow signing other peoples commits in
the future, but not yet.

>> As a first draft, I would really consider setting it to require that the
>> email addresses match. But I don't know how to extract the address from
>> gpg. And I assume you would want the rich pyme/libgpgme interface,
>> rather than calling out to gpg --verify and reading the output of stderr.
> 
> I had the impression that gpgme was in fact just a parser for gpg's
> batch output, but I might be wrong.  So then it's just a matter of
> whether it's easier to link it, or easier to correctly parse out 
> the bits we want.
> 

My understanding of libgpgme is that it uses all of gpg's extra flags
for error reporting and process handling. Specifically the flags like:
--status-fd, --logger-fd, --attribute-fd, etc.

I think it would ultimately be easier to just include pygpgme, but I
haven't looked into it yet. (pyme was pretty ugly to use when I checked
into it last year).

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060510/41895ad0/attachment.pgp