On 10/11/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> Hi,
>
> This is a fix for a problem originally described here:
> http://svn.haxx.se/dev/archive-2006-09/0994.shtml
>
> Specifically, if GSSAPI is part of the list of mechanisms sent by the
> server, the client will always choose it over the others (because it's
> the most secure) even if it isn't really prepared to use it (e.g.
> because there are no Kerberos credentials). Thus authentication will
> always fail. The correct behavior would be to retry authentication
> with the next best mechanism, which is what this patch does.
>
> The patch isn't specific to GSSAPI, but AFAIK only GSSAPI exhibits the
> problem that this patch is trying to fix.
>
> [[[
> 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.
>
> * subversion/libsvn_ra_svn/sasl_auth.c
> (try_auth): If sasl_client_start() fails with a non-fatal error message,
> delete the current mechanism from the list and try again.
> ]]]
So, I've been playing with this patch, and it seems generally fine
(still got that weird set of failures in svnsync_tests.py, but that's
not new), but I did notice one problem with the sasl code, and it's
unrelated to this patch.
When I run the svnsync tests with --enable-sasl it's crazy slow. Like
basic_tests.py usually takes me under a minute, but when I turn sasl
on it takes like 6 minutes to finish. This seems bad to me...
Anyway, this patch does fix a real problem, so I'll likely commit it
soon, I just wanted to ask if anyone else was seeing the crazy
slowdown with sasl turned on, and if so if they know what's causing
it...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 24 21:39:24 2006