On Fri, Nov 30, 2012 at 7:17 AM, Eric S. Raymond <esr_at_thyrsus.com> wrote:
> Normally, access to the Subversion repositories I use is actually authenticated
> via an ssh key used for login to the server host. I'm not sure in what sense
> the username field actually contributes any security-relevant information
> in a setup like that. Does it?
That's what Branko and I are trying to say. username is not sent to
the server outside of whatever authentication method the protocol
uses.
In the case of svn+ssh username is never going to be sent to the
server since you're going to use the tunnel's authentication. So the
svn:author field will be filled with --tunnel-user if passed to
svnserve or the username of the uid svnserve is running as.
The issue you're seeing here is actually called out in the book:
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.choosing.html
[[[
* Only one choice of authentication method is available.
]]]
and
[[[
If you have an existing infrastructure that is heavily based on SSH
accounts, and if your users already have system accounts on your
server machine, it makes sense to deploy an svnserve-over-SSH
solution. Otherwise, we don't widely recommend this option to the
public. It's generally considered safer to have your users access the
repository via (imaginary) accounts managed by svnserve or Apache,
rather than by full-blown system accounts. If your deep desire for
encrypted communication still draws you to this option, we recommend
using Apache with SSL or svnserve with SASL encryption instead.
]]]
For your particular use I'd think that http would be a much better
access method since Apache provides you a lot more flexibility with
the authentication method.
But again, if you want svn:author to be set to some value a user sets
locally and that has doesn't necessarily have anything to do with
their authentication to the server, you can't do that with username
configuration. Since there is absolutely no guarantee that username
will even be sent to the server.
Received on 2012-11-30 17:12:20 CET