Re: Can svnserve read an encrypted password file?

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
Subversion?

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