Enforcing usernames (was: Improving support for signed revisions)

Lasse Kliemann lasse-list-mercurial-2009 at mail.plastictree.net
Tue May 26 19:10:55 CDT 2009


* Message by -Lasse Kliemann- from Sun 2009-05-10:
> * 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 :-)

I did that, please have a look at:

http://plastictree.homeunix.net:8080/hg.cgi/hgssh

(Yes, I also took the opportunity to set up a web-based Mercurial 
server; hope everything works.)

The code of the extension is just a few lines, so maybe someone 
can have a look at it and see whether it is alright. For 
instance, I am not exactly sure how this works:

   xrange(repo[node], len(repo))

I took this from the acl extension.

BTW, I am still looking forward to help with the commitsigs 
extension. I'll be quite busy for the next 1 1/2 weeks, however. 
I'll get back to it after that.

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


More information about the Mercurial mailing list