Improving support for signed revisions

[Lasse Kliemann]

* Message by -Lasse Kliemann- from Sun 2009-05-10:

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

A simple form of this could work without signatures and might be 
straight-forward to implement. The server makes its check as 
described: it compares the user given by '-u USER' with the 
'user' entry of each and every new arriving changeset of the 
push. If they all match, the push is allowed. If there is any 
mismatch, the whole push is aborted.

Users can so trust the 'user' entries in the changesets whenever 
they clone or pull from the server. Hence, this is a centralized 
model. It would be sufficient for my applications for the time 
being. It sounds so simple, maybe even I can implement it :-)

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