On backporting r21531 to 1.4.x.

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.

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.)

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.

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.

What do others think of this situation?

(You might want to hold off on responding until someone corrects all the
technical details I surely failed to accurately relay in this mail.)

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand