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

Re: sasl mechanisms order

From: Victor Sudakov <sudakov_at_sibptus.tomsk.ru>
Date: Sun, 22 Aug 2010 12:17:41 +0700

Colleagues, I understand that you are expecting a patch. I am sorry, I
am a systems administrator and not a programmer, my code writing
ability does not go beyond scripting.

Victor Sudakov wrote:
> I have subversion-1.6.12 compiled with cyrus-sasl-2.1.23 from ports,
> FreeBSD 6.4.
> I need to guarantee that the subversion client/server will always use
> the GSSAPI mechanism before DIGEST-MD5. In a more general sense, one
> may need to set the order of SASL mechanisms for authenticated users.
> However it seems that there is a stalemate situation.
> According to Daniel Shahaf, the subversion client uses the
> server-reported mechanisms, in the order suggested by the server.
> "There is no knob that lets you manipulate the order in the client."
> Please see the thread "sasl mechanisms order" in users@ for more
> details.
> According to Alec Kloss, "the order of the offered mechanisms from
> Cyrus sasl is, by default, the reverse of the order that the library
> finds them. This would be, in effect, the reverse physical directory
> order of the modules in /usr/[local]/lib/sasl2/ which you can find
> with ls -U. [...]Cyrus SASL believes it's the client that should
> select the preferred mechanism from the list offered by the server,
> not just the first one."
> All this means that if perchance I touch a file in
> /usr/local/lib/sasl2/, my Kerberos SSO can stop working.
> Could we think of a way to manipulate the order? Perhaps svn needs an
> option like the one OpenLDAP utilities have:
> -Y mech
> Specify the SASL mechanism to be used for authentication.

Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
Received on 2010-08-22 07:18:25 CEST

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.