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

Re: svnserve LDAP support (was: RE: Speed issues with ra_neon to remote repositories)

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 26 Jun 2009 00:23:47 +0100

On Fri, Jun 26, 2009 at 12:13:28AM +0200, Johan Corveleyn wrote:
> > -----Oorspronkelijk bericht-----
> > Van: 'Stefan Sperling'
> > - It introduces a dependency on the ldap library without adding the
> > necessary config foo to the configure script
> > - It does not follow our coding conventions consistently, some of
> > the spacing looks really wrong
>
> Ok, but those last two problems are kind of peripheral. I agree the
> patch could be improved after some review (follow coding conventions,
> fix configure script, add tests, ...), but that's a minor detail from
> my point of view.

Yes, they are minor details, but they take time...

> I'd leave the security issue up to the responsibility of the people
> installing svn this way. It's their call to make if they don't set it
> up securely, and just trust their closed, private intranet in some way
> (or to secure it by other means). As long as it's clearly documented
> that the passwords are transmitted in clear text, it seems fine to me
> ("and if you don't like that, use Apache+ssl+svn"). I figure there are
> also shops that don't bother with SSL, and use Basic Authentication
> over plain http...

Yes.

> > If we then also amended the documentation to tell people to set up
> > a VPN or stunnel or similar to secure communication to saslauthd,
> > that's fine by me.
> >
> > Would this make you happy?
>
> :). I don't have any personal interest in this feature anymore, since
> we've switched to Apache+SVN. It took some work, but now we're happy
> mod_dav_svn users. I just joined the discussion because of my past
> experiences with svnserve, and to help out other (future) SVN admins
> encountering this problem. Anyway, it would certainly add some closure
> :).

Heh, OK.

> To the point: it's a workable solution of course, but nowhere near as
> convenient as the patch proposed by Eugene Ivlev.
> - SASL is still very difficult to setup/configure/troubleshoot for a
> lot of people. Compared to the 5 line configuration in svnserve.conf
> (with the other patch), there is a huge difference.
> - Using LDAP with SASL requires running an extra daemon on the server
> (saslauthd). That makes it more complex, less robust, ...
> - SASL doesn't give you LDAP support on Windows (see
> http://www.sendmail.org/~ca/email/cyrus2/windows.html - no saslauthd).
> So you'd exclude svnserve setups on Windows.

> I'd still prefer that other patch. OTOH, any LDAP support is better
> than nothing.

Since it will help in some environments, I will commit the patch.
The assumption that SSL is the only answer to plain text passwords
is just wrong. This should also fix a recent complaint made about
the svnbook documenting LDAP as a possibility for svnserve even
though right now it's impossible to use it (as far as I've heard).

And the patch won't stand in the way of adding direct LDAP support
or SSL support in the future.

> > Would you be willing to make the necessary documentation updates?
>
> Hm, I'm really extremely busy lately (and doubt that's gonna change
> soon). But then again, isn't everyone?
> If you would decide to implement this patch (or even better, the other
> one :)), I'll see if I can make some time to make my own contribution
> ...
>
> But where/how do I do this? Any pointers, where to start?

Well, the docs are kept in two places. Some small bits are in the
Subversion source tree itself (notes/ directory, help output).
Most of it is in the svnbook.

For contributing to Subversion, see http://svn.tigris.org/hacking.html
For contributing to the svnbook, see http://svnbook.read-bean.com (which
is down right now, unfortunately).

Stefan
Received on 2009-06-26 01:25:41 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.