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

Re: Can svnserve read an encrypted password file?

From: Alec Kloss <alec.kloss_at_oracle.com>
Date: Fri, 29 Aug 2008 07:23:26 -0500

On 2008-08-29 10:57, Stefan Sperling wrote:
> On Fri, Aug 29, 2008 at 10:21:23AM +0700, Grigory V. Kareev wrote:
> > If you want to host multiple repositories using one svnserve process,
> > cleartext passwords stored either in ldap, sasldb or svnserve db
> > is the only option currently, IMO.
> >
> > Possible solutions are:
> > a) TLS support for svn client and svnserve (in this case we can use
> > sasl cleartext password transmitting auth methods like PLAIN or LOGIN
> > and svnserve will be able to do checks against any encrypted passwords db)
> > b) alter svnserve internal CRAM-MD5 auth method and make it work with
> > stored passwords hashes as described here:
> > http://southbrain.com/south/2008/08/cmusaslsecretcrammd5-cmusaslse.html
> > c) add svnserve config or command line option to disable internal CRAM-MD5 mech
> > and let the sasl do all checks
> I would not expect good patches which implement either a, b, or c
> to be rejected :)

I've thought about doing (a). There was a draft once upon a time
for adding TLS to SASL itself but I don't think it went anywhere.
One could either implement such a thing, in which case this becomes
purely an issue for SASL, or one could implement "svns://", a
TLS-tunneled svn protocol connection. "svns://" wouldn't require
a new SASL mechanism so would probably be quicker to get off the
ground, but there are some real perks to having SASL in general
support TLS. Any thoughts about what would be preferred for

I'd never heard of (b) prior to now. It makes some sense, but I
think you'd want to get the SASL mechanisms extended to handle the
idea of a "hashed password" CRAM-MD5 secret, or else I fear the
interoperability problems will be substantial. Also note that
these hashed keys become password-equivalent so to some people,
there's not much of an improvement here. (As I understand it, krb5
justifies the password equivalents by only storing them on the KDC,
and then hardening the KDC to prevent disclosure.)

Alec.Kloss_at_oracle.com			Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956

  • application/pgp-signature attachment: stored
Received on 2008-08-29 14:24:03 CEST

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.