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

Re: [PROPOSAL] A new (simple) authentication mechanism for svnserve

From: Chris Lott <chrislott_at_spamcop.net>
Date: 2005-07-28 19:16:00 CEST

David Anderson <david.anderson@calixo.net> wrote:
> I can understand why you'd like some other storage mechanism here.
> However, Greg's point on why we shouldn't keep on expanding what was a
> temporary fix to the absence of a real SASL library is very good.
> ..

Seems like this is a classic trade-off between security and usability.

Please correct me where I go wrong here: I guess that use of a Simple
Authentication and Security Layer (SASL) would require svnserve to make contact
with some other process on some machine. Would that additional program be
something supplied by the subversion project, or would a program from some
other open-source project be used? Either way, I'm guessing that the SASL
process would require root's care and feeding. So the addition of SASL would
change the relatively simple svnserve setup (one simple enough for users to
administer) into something much more like https/Apache/DAV access in terms of
the config complexity and admin support required. At that point, it would
probably no longer be fair to describe svnserve as a "simple" alternative to
Apache :-)

Maybe you're saying that svnserve would negotiate an SSL session each time a SVN
client connects to it. Given the availability of OpenSSL, is this difficult?
Would this allow eliminating cleartext keys because replay attacks are then
very difficult? The new complexity in that situation is an SSL certificate (I
think). Would one be required per repository served by svnserve, or only per
machine where svnserve is running? Ideally the latter, so the hassle can be
limited to install/setup, not each time a user wants to create a new
repository.

The proposed password-management policy of generating/caching obscure passwords
for all SVN users, as Greg Hudson stated, only lessens the chance of a user
storing a password that s/he uses widely on various systems. I agree that in
our case, everyone works for the same company, so they should ask each other
for access instead of taking it. But the cleartext issue seems like an
avoidable hole.

One small item -- David Anderson's original proposal states that cleartext
passwords are not a security issue. Well, I guess I beg to differ; I feel it
is a real security issue.

Thanks for the quick reply.

chris...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 29 01:15:56 2005

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