[ANN] autosign extension

[Lasse Kliemann]

* Message by -Martin Geisler- from Wed 2009-05-13:

> We should parse the output like the gpg extension does -- line by line.
> That is a bit simpler (and it thus feels safer) than using regular
> expressions.

I took a look at it in the gpg extension. Looks straightforward. 
I'll follow that approach.

 
> > However, I would prefer something quite different. We could allow a
> > configurable set of pairs (F,U) consisting of a key fingerprint F and
> > a username U each. The configuration could be done in ~/.hgrc or such.
> >
> > Verification would work as follows. Let C be a changeset and S 
> > its signature. Then S is considered _valid_ for C if there exists 
> > a pair (F,U) such that:
> > * S it is a good signature for C (in the sense of gpg --verify) 
> >   for a key that has fingerprint F 
> > * and U is the exact string in the 'user' field of C.
> >
> > Then, I can say: well, I know a co-worker by some name U, and he signs
> > his changesets with a key that has fingerprint F. I would then add
> > pair (F,U) to the list in ~/.hgrc. After each pull, I would run 'hg
> > checksigs'. If it does not complain, I henceforth know that I can
> > trust all changesets bearing the name U of the co-worker to truly
> > originate from him. So, I would do a verification once, and henceforth
> > could simply rely on the output of 'hg log'.
> >
> > Advantages: no fiddling with signatures on keys (to increase their
> > trust), and no need for committers to have the exact same username in
> > Mercurial ([ui] username = ...) which they have on their key.
> 
> I like that scheme: simple and flexible. I think we should go with it.
> 
> I had another idea in mind: what about simply asking people to not put
> untrusted keys into their keyring? Or better: have the extension use a
> custom keyring, configured by the user? That might go a long way and be
> even simpler.

Untrusted keys in the keyring are not so much of a problem if the 
autosign extension insists on keys being marked at least 'fully 
trusted' (like I proposed). Users can enforce that trust level 
locally by a local signature ('gpg --lsign...'). So they can 
import anything they like into their keyrings, provided they are 
careful which keys they sign. However, there is still an issue 
with this, surprisingly, which I do not see how to handle. That 
is: signatures on keys (like with '--lsign') have to be seen in 
conjunction with user IDs on the key. So, when signing a key, the 
real testimony made is that this key belongs to the person known 
(in some context) under the user IDs on the key. Now, additional 
user IDs can be added later. If I import a key X with a user ID 
A, and I '--lsign' it, then the key is locally trusted to verify 
authorship by the person known under A. Now, assume the owner of 
key X adds an additional user ID B, by which someone else is 
known, so this is a 'false' user ID. Assume furthermore that 
somehow it happens that I import the modified version of key X.  
Then, I have key X with user IDs A and B in my keyring. My local 
signature only covers A, and this is all well. However, and here 
comes the punch line, I do not know a way to get that information 
out of gpg in an easily parseable format! It *is* shown with 
'--list-sigs', but this is not so very parseable. I did not 
figure out how to obtain this information from the output that is 
given with '--status-fd'. Maybe someone knows something. 
Otherwise, I might ask on the GnuPG mailing list.

Bottom line is: for now, it would in fact be easiest to let users 
specify separate keyrings. This should be configurable per 
repository. Users should then only put keys with correct user ID 
in that keyring, and we could use '--trust-model always' to spare 
users the '--lsign' business.


> > X.509 should be supported, yes. We would have to adopt the above
> > scheme of fingerprint-username pairs to it, if accepted. I could make
> > a proposal for it then.
> 
> Please go ahead... I have no big need for this extension myself, I just
> figured it would be cool to have :-) So I don't think I will be driving
> the development very actively, at best I'll be stearing it.

I have a concrete idea how to include X509 with OpenSSL. I have 
to check out some things on the OpenSSL mailing list first. I'll 
present it here shortly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090514/daa23704/attachment.pgp