[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnserve question

From: David Anderson <david.anderson_at_calixo.net>
Date: 2005-08-23 13:20:38 CEST

Claudio Ochoa wrote:

>> Soon, this should also be possible at a finer grained level,
> David, thanks for your answer. How soon is soon?

Soon as in "the patch which implements it has just been posted for
review on the development mailing list". I have no voice in what goes
into which release, but I'd expect the feature to be scheduled for
1.3.0, whenever that is due to happen.

> Basically, our system users use svn+ssh since that allow us not to send
> cleartext passwords. Besides that, we want to allow non-system users to
> read-only access our rep, without having to create a system account for
> them, and without allowing anonymous access. This is the reason I
> thought using svn would help us. I don't know if this answer your question.

Yes and no. Like I said in my rant, svn:// doesn't actually send any
usable password token in cleartext. That's why the passwords are stored
in cleartext on the server - so as to allow an authentication protocol
that does not reveal an authentication token usable in a replay or plain
password theft attack.

svn+ssh doesn't add any security in that respect; what it does provide
is the capacity to plug into lots of auth systems (which svn:// doesn't
do yet), and to have a digital certificate for the server (which svn://
also doesn't do yet). Other than that, you could just set up plain svn
access, with the pre-commit hooks I spoke of, and sit and wait for authz
to come along in a future release. Depends on what you need.

- Dave.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 23 13:23:14 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.