C. Michael Pilato wrote:
> Sitting in 1.4.x/STATUS at the moment is:
>
> * r21531
> Allow HTTP auth protocols to be configurable by way of a
> "http-auth-types" parameter.
> Justification:
> Allow use of GSSAPI/SSPI auth on Windows with Neon 0.26.1+.
> Votes:
> +1: dlr, djh
> -1: cmpilato
>
> Why the -1 from cmpilato? Because r21531 adds a new runtime
> configuration option, and I feel icky gross about adding a runtime
> configuration option in a patch release. As written, the STATUS item
> reads like a new feature addition, which further strikes me as not a
> suitable candidate for patch release backport.
If I may add my comments here too:
this is a really big issue for TSVN. Many users are complaining that
they can not connect to their repositories anymore because of the always
enabled SSPI authentication. I had a bad feeling when I activated it in
TSVN even though Subversion 1.3.x already had activated it. And now I
have to live with it - I guess there are just much more Windows users
only using TSVN and not the command line client. Otherwise you guys
would have to deal with those users too.
If it takes again almost a year until the next 'big' Subversion release
I will have to buy a lot of Valium to survive all the complaints, or
have users not update and still use an old version (which means I have
to deal with bugs long fixed too).
> But in IRC a few minutes, some more of the details of r21531 started to
> spill out, and the issue is more complicated that it would seem at first
> glance. (Complicated enough that I'll probably botch this summarization
> attempt.)
>
> Prior to the change made in r21531, Windows users with Subversion's
> compiled against Neon 0.25.x suffered from the following problems:
>
> * GSSAPI/SSPI support didn't worked over SSL.
>
> * Your Windows credentials were passed over the wire without
> you having authorized such a thing in an automated attempt to
> authenticate. (At this point, if not earlier, my knowledge gets
> shaky, and I have to presume that if those creds failed against
> the server, some graceful fallback to Basic or Digest auth worked
> just fine -- but I dunno.)
No, it wouldn't fall back to basic auth. At least not in all
circumstances. One problem for example is that the authentication can
succeed (if the user is part of a domain which the server hosting the
repository is part of too), but later the authorization fails. In that
case, Subversion simply gives up with an error and doesn't try to
reauthenticate (because the authentication was successful before).
This can happen if e.g. the GUEST account is enabled on the domain
controller (sometimes it has to be, due to other company apps requiring
that). Or if the admin has set up different user accounts for the
repository than the users use to log in to their workstations (happens a
*lot* from what I get on the mailing list).
> Neon 0.26.x had the same issues, save that a new API was added which
> allowed programs to specify which of the authentication methods Neon was
> to attempt (a bitmask of sorts). This allowed folks who weren't using
> Neon in GSSAPI/SSPI-authenticated manner to not transmit their Windows
> creds over the wire.
That was added due to my request on the neon mailing list. I also
reported the very same issue several times on this mailing list, way
before the 1.4.0 release. I also mentioned that I'm not familiar enough
with that part of the Subversion code to implement this myself and that
someone should please implement this before the release.
(if you feel that I'm getting a little annoyed with how people treat my
requests and concerns on this list, you're right - it happens way too
often that I could say "told you so".)
> Here's where Subversion comes in.
>
> r21531 detects Neon 0.26.x, and, if present, allows you to use a new
> runtime configuration option which maps to that Neon bitmask
> choose-your-authn-methods interface. This permits users to indicate (on
> a per-server basis) which authn methods they want to use, which
> ultimately affords them protection against transmitting GSSAPI/SSPI auth
> creds to servers that can't use them. It also turns on
> SSAPI/SSPI-over-SSL, but, of course, only in accordance with the runtime
> option.
>
> Now, I fully appreciate the problems that the Windows users are facing,
> but my default stance on how I view patch releases causes me to pause
> when someone mentions new APIs, new command-line parameters, new runtime
> configuration options, etc. However, it does seem rather crazy to make
> Windows users wait until 1.5.0 for this (crazier still to rush 1.5.0
> *because* of this). I asked on IRC if there was some way for Subversion
> to programmatically choose a sane default behavior in the 1.4.x line,
> but it doesn't appear that that's really on the table so long as not
> auto-transmitting Windows auth creds is one of the primary goals.
The only way to disable the automatic authentication with SSPI is by
disabling it during compile time. I did that for TSVN 1.3.x even though
the command line client had it activated for the 1.3.x versions. The
problem was/is that with SSPI disabled, people behind certain proxies
can't connect to their repositories because the proxy requires SSPI too.
And during the time TSVN 1.3.x was the current version, I got a lot of
complaints about that (most of the time with the hint that the command
line client works).
The only "solution" for me would be to ship two versions of TSVN, one
with SSPI enabled and one with SSPI disabled. Since I already have to
ship two version (win32 and x64) I would have to ship four(!) different
TSVN versions every time.
I hope you can understand that I don't like that idea at all.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 9 20:19:57 2006