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