Signing revisions in place

[Jens Alfke]

I've been musing a bit about digital signatures on revisions. This is  
a valuable feature in distributed development since it allows you to  
trust the authorship of changes (assuming you have sufficient PKI that  
you can reliably associate a public key with an identity.)

Monotone has built-in support for this. Mercurial has an extension  
(gpg), but it appears to work after the fact by committing a new child  
revision that contains the signature for its parent. I don't like this  
approach because it adds yet more revisions, and because it seems to  
be easy to "lose" the signatures — for example, if I pull revision n  
from another repo, I don't get the signature with it, so my repo now  
lacks the ability to authenticate n. Instead I have to remember to  
find the signed child of n and pull that instead.

How about an alternative approach? It seems feasible to sign a  
revision directly by adding the signature to the revision data itself.  
As I understand it, a revision's data consists of the manifest's hash,  
followed by metadata like the date, branch, author, ending with the  
checkin comment. If a hook took that data, generated a signature, and  
then appended the signature to the checkin comment, the resulting  
revlog entry would be signed. To verify it you'd just locate the start  
of the signature, and verify that the data up to that point matched  
the signature.

Actually I just found evidence of a similar practice in the existing  
mercurial-stable repo, in some revisions starting with Matt's checkin  
DB3AA85B "Add manifest hash to commit messages for easy signing".  
Looks like people were copying the manifest hash while composing their  
commit message, manually generating a GPG signature of it, and  
appending the signed text and signature. That's reasonable, but (a)  
it'd be nicer if this were automatic, and (b) that mechanism doesn't  
sign all the revision metadata. So I could take someone else's signed  
revision, modify the date, prepend something inaccurate before the  
signed manifest, and pass it off as their revision. (Of course the  
hash would be different; but no one would be able to tell which  
revision was authentic.)

Thoughts?

--Jens