[ANN] autosign extension

[Lasse Kliemann]

* Message by -Dan Villiom Podlaski Christiansen- from Fri 2009-05-15:

> 1. the signature is valid and trusted.
> 2. the signature is valid but not trusted.
> 3. the signature is valid, but doesn't correspond to an author or
> committer/signer specified in the changeset.
> 4. the signature is valid and trusted except the certificate has
> either expired now or on the date specified in the changeset, or has
> been revoked, possibly since then.
> 5. the signature is corrupt; the changeset does not validate according
> to the signature.

I assume that with "trusted" you mean: "a user ID on the 
corresponding public key which is certified with a trusted 
signature (either via a X509 certificate or via a signature on an 
OpenPGP key) can also be found in the 'user' field of the 
changeset". Then the most interesting distinction is between case 
1. and the rest (cases 2. to 5.).


> The most important scenarios to me is what happens in the final case:
> I would expect Mercurial to abort with a hard error, as soon as
> possible when seeing such a changeset. I would also expect that the
> only way to solve it would be getting rid of that changeset.

I am not sure about this. It might be decided that the changeset 
is okay, after inspecting its contents. There should be a way to 
permanently express that decision.


> I would also expect Mercurial to disallow signing with an address not
> specified in the certificate, [...]

Or at least display a warning. I already had thought about that. 
It should be easily integrated in the extension.

> and issue clear warnings whenever an
> untrusted signature is seen. To me, signature support should
> prioritise security and safety over usability and convenience; after
> all signatures are useless if you cannot rely on them.

I agree on this. Signatures should feel to users like being 
somewhat mandatory, as opposed to being some fancy optional thing 
to play with.


> I don't know how valid signatures should be shown, but perhaps marking
> unsigned or improperly signed changesets instead would be better?
> 
> For what it's worth, I'd prefer it if you didn't have to run a
> separate command to check signatures, but if checking occurred
> transparently behind the scenes whenever accessing a changeset.

The current efforts will first yield a two-command solution. You 
run 'checksigs', and if it does not complain, i.e., each and every 
changeset has a signature that is fine in the sense of case 1., 
then you can trust the output of 'hg log' henceforth, up to the 
next time that changesets from an outside source come in (most 
likely via pull).

On the long run, I would clearly vote for extending the 'log' 
functionality to show with each changeset how things are 
concerning the signature. Maybe nothing should be shown for case 
1., and some easy-to-recognize warning should be shown in one of 
the other cases. Since verifying signatures takes time, we would 
have to think about caching.

-------------- 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/20090515/1966488e/attachment.pgp