Improving support for signed revisions

[Lasse Kliemann]

* Message by -Martin Geisler- from Sat 2009-05-09:
 
> 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.

I've got the suspicion that this can make matters even more 
dangerous. It depends on how one is supposed to interpret a 
signature. Assume that I have username A; it is in my OpenPGP key 
and I use it as my Mercurial username. Anyone can commit 
changesets with username A, but only I can make signatures with 
my key. Now, assume furthermore that we were to interpret a 
signature by my key on a changeset in the following way: to 
testify that all its ancestors which show username A are in fact 
by me. Then, if someone, who was not me, at some point of time in 
the past had committed a changeset with username A, without me 
noticing it, then I would make that changeset authorative by my 
signature on a later changeset. Which is of course not what I 
want, because it's false security, which is even worse than 
uncertainty.


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

Maybe we could do something similar. The server tells users apart 
by their SSH keys. So, 'authorized_keys' looks like:

   command="hg-ssh -u USER ALLOWED_REPOS ..." ...

with an imaginary '-u USER' option for 'hg-ssh'. Upon every push, 
the server checks every new changeset whether it in fact bears 
the appropriate username, i.e., the name given by '-u' in that 
line of 'authorized_keys' that corresponds to the SSH key by 
which the user had authenticated himself on the server. When that 
check is okay, then the server puts a signature testifying 
exactly what he has just checked. Maybe the signature should be 
done as a separate changeset (like the currently available GPG 
extension does), and it should somehow express the list of 
changesets for which the username was checked. The testimony 
should not implicitly stretch across all ancestors (although they 
are also signed by this; but I'm talking about the testimony 
here, i.e., which statement we wish to associate with a 
signature). We would also need some code to verify these 
signatures and to list changesets that should not be considered 
authorative.

I am not sure, however, whether this approach is worth 
implementing. Maybe implementing signatures for each and every 
changeset instead would not be more involved and also the cleaner 
way to go. It would also follow the idea of a distributed system  
more closely. If going for it, I would also vote for doing it 
with X.509 as someone recently suggested. AFAIK the Monotone 
project does something similar.

-------------- 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/20090510/0a6d7df9/attachment.pgp