Signing revisions in place

[Dustin Sallings]

   I like the idea of signing tags quite a bit.

   gnu arch allowed one to sign each revision.  I'm not sure if that's  
generally valuable here, but if one could be confident in a signature  
on a revision hash, and confident that the correct tree could be  
generated from that hash, I think the solution is pretty solid.

-- 
Dustin Sallings (mobile)

On Oct 3, 2007, at 10:42, Jens Alfke <jens at mooseyard.com> wrote:

> 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
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>