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

Re: [PATCH] SASL support ready for review and testing

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-07-10 19:02:28 CEST

On 7/10/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> Hey folks,
> I finally have something for you to play with. Before I get into
> details, here are a few things you should know:
> 1. To implement security layers (i.e. encryption) I used the
> svn_ra_svn_stream_t implementation from the svnserve-ssl branch.
> 2. I haven't tested this patch with GSSAPI or KERBEROS_V4. If you have
> a working Kerberos setup, you are encouraged to try this out.
> 3. No win32 support yet.
> To test this:
> - Install Cyrus SASL version 2.0.0 or later
> - Put this in your svnserve.conf:
> [sasl]
> use-sasl = true
> min-enc-strength = 0
> max-enc-strenght = 256
> min-enc-strength and max-enc-strength are the minimum and maximum encryption
> strengths that you want SASL to provide. 0 means no encryption, 1
> means integriy-checking only, and values greater than 1 correspond to
> the key length, in bits. Both options default to 0 at the moment.
> - Put this in your /usr/lib/sasl2/Subversion.conf :
> pwcheck_method: auxprop
> mech_list: ANONYMOUS CRAM-MD5 DIGEST-MD5 .. etc
> Cyrus SASL also supports another password-checking method via a
> standalone daemon, saslauthd. It only works with plaintext passwords
> though, so until we have SSL support for ra_svn, it doesn't make much
> sense to use it.
> There are many more options that you can specify. See the SASL docs
> for details.
> - Add users to the password database:
> # saslpasswd2 -c user -u realm -a Subversion
> Replace realm with the realm specified in svnserve.conf.
> - Make sure the user who owns svnserve has read access to the password
> database (usually /etc/sasldb2). If you are going to use OTP you also
> need write access.

First off, this is fantastic progress. I do worry though, that this
patch is awfully large. I'd really prefer if you finished off, for
example, just the client side of things, and got that in shape for
commit, then sent in a separate patch for server side support. As it
was we were getting quite close to being able to get the client code
in, but now it's all intermingled with the server side of this patch,
which makes it that much harder to review.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 19:02:58 2006

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

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