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

Re: [PATCH] Make SASL mechanism negotiation smarter

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-10-11 14:53:22 CEST

Hi Vlad,

On Wed, Oct 11, 2006 at 01:59:04PM +0300, Vlad Georgescu wrote:
> If a SASL mechanism fails sufficiently early (i.e. before the client
> sends the initial response), don't automatically fail the
> authentication. Instead, fall back to the next best mechanism sent by
> the server.

I'm also having a problem with the SASL-enabled svnserve - and while it's
not completely identical to the problem you're fixing here, I suspect
it's in the same area.

The problem I have is that if I link to the SASL libraries (which happens
by default), I can no longer establish a non-SASL connection. That is,
there appears to be no fallback from the SASL negotiation to the non-SASL
negotiation (of anonymous, cram-md5).

Specifically, I get the following error:

$ basic_tests.py --url=svn://localhost:3691 1
../svn-trunk/subversion/libsvn_ra_svn/sasl_auth.c:339: (apr_err=170001)
svn: SASL(-4): no mechanism available: No worthy mechs found
FAIL: basic_tests.py 1: basic checkout of a wc

Which, arguably, is correct, as I have no configured SASL mechanisms
that can be used by the client to prove the user's identity to the server.

[Incidentally, I presume that these are done on a per-service basis or
similar? We're not going to ship in a mode that suddenly allows every
valid account in /etc/passwd to commit to a repository, are we?]

Anyway, the current situation is a not a good user experience, especially
as I have no reason to enable SASL myself (though I _do_ need the SASL
libraries to be installed for some other applications).

Can we not fall back to the previous authentication mechanism if SASL
doesn't have any matching authentication mechanisms?


  • application/pgp-signature attachment: stored
Received on Wed Oct 11 14:53:40 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.