Improving support for signed revisions

[Martin Geisler]

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

> * Message by -Lasse Kliemann- from Thu 2009-05-07:
>
>> The desire to mark certain revisions as trustworthy gives motivation
>> for providing as many signatures as possible, in the best case for
>> each revision. He who wishes to provide a signature for signalling
>> trustworthiness might have a much easier job if he can trust certain
>> committers *and* he can trust that a commit allegedly made by one of
>> these trusted committers was in fact made by that trusted committer.
>> 
>> I wonder how one could otherwise make sure that a revision is
>> trustworthiness, unless one *in* *detail* (e.g., by looking at all
>> the diffs, line by line) checks each and every commit made since the
>> last trustworthiness signature.
>
> To put it another way: without some crypto sig on each revision, it is
> even impossible to tell whether two revisions were made by the same
> person. The 'user:' entry for a revision is similar to the 'From:'
> header in an e-mail: the sender can put anything there, claiming to be
> anyone else.

I know and I agree that it would be a nice feature to have signatures on
each changeset. It would make it easier for people to look at a
changeset in isolation and judge whether or not to trust it.

But do remember that when I sign a changeset I am really signing the
changeset *plus* all its ancestors.

The signature is on the changeset hash, and the hash is the root hash of
a hash-tree that includes all the ancestors. This implies that I don't
have to sign all the intermediate changesets for you to trust them.

That means that if you have a tree like this:

  [A] --- [S(A)] --- [B] --- [C] --- [D] --- [S(D)]

where the S(X) changesets are the signature-commits, then you should
treat changesets B and C and signed too (unless you think the hash
function is broken).

So you could ask people (or maybe enforce it with a hook) to always sign
before pushing to a public server, i.e., to ensure that the head
revision(s) on the public server is always signed. That would give you
the same security guarantees with fewer signatures.

-- 
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/20090509/ff66e7a1/attachment.pgp