[ANN] autosign extension

[Martin Geisler]

Lasse Kliemann <lasse-list-mercurial-2009 at mail.plastictree.net> writes:

> * Message by -Martin Geisler- from Wed 2009-05-13:
>  
>> So please go test it:
>> 
>>   http://bitbucket.org/mg/autosign/src/tip/autosign.py
>
> Thank you for your efforts!
>
> Some suggestions and observations:
>
> 'checksigs' seems to ignore the first revision if no revision is
> specified. See the attached patch for what maybe a simple fix (start
> range at 0). (BTW, I had never written a line of Python code before.
> Please excuse any uglyness in my patch.)

Nope, it's fine, you're now a Python developer! :-) I refined the patch
a tiny bit and pushed it:

  http://bitbucket.org/mg/autosign/changeset/9f79bb2fb7b1/

It would be even better if you committed the change and did 'hg export
tip' to get a patch with the full Mercurial meta data (date and
committer name).

To prove the point of this extension, I commited it with your
username... :-) That actually points to a problem: even if you had made
the patch with 'hg export' or the patchbomb extension, its signature
would have been lost.

> The test for 'GOODSIG' in the output may be too weak. Someone might
> just create a key with 'GOODSIG' in the username.

Heh, yeah, that's not so good :-) That was indeed just meant as a quick
test to get things working...

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.

> See the attached patch for a first attempt to fix this (and to
> implement the scheme sketched in the next paragraph, which I however
> do not consider a final solution; see further below for that).
>
> We need a way to connect the 'user' field in the changeset with the
> key. More precisely: there should be a way to specify which keys are
> allowed to give - via a good signature in the sense of 'gpg --verify'
> - testimony about authorship of which users. A straightforward way is
> to only consider a signature valid if the username in the key matches
> the username in the 'user' field of the changeset. This is a common
> practice with signed e-mail (username in key is compared to 'From:'
> header). This alone is not enough, however, since anyone can create a
> key with anyone's identity. As an additional measure, the trust of the
> key could be considered.

Hmm... it's true that the keys should be trustworthy, but I hope we can
defer that decision to the normal web of trust mechanisms. Ideally, the
extension should simply say "this changeset has a valid signature from
this key" or "no valid signature found".

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

> 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 hope we can get it ready for inclusion in Mercurial 1.3 which is due
July 1st. That gives us 4 weeks at most to come up with something
stable, see:

  http://www.selenic.com/mercurial/wiki/TimeBasedReleasePlan

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090513/e9ba15bb/attachment.pgp