[PATCH] support SSPI for Windows

[Chuck.Kirschman at bentley.com]

> -----Original Message-----
> From: Matt Mackall [mailto:mpm at selenic.com]
> Sent: Sunday, April 15, 2012 8:16 PM
> To: David Pope
> Cc: Henrik Stuart; Chuck Kirschman; sune.foldager; mercurial-
> devel at selenic.com
> Subject: Re: [PATCH] support SSPI for Windows
> 
> On Sat, 2012-04-14 at 10:36 -0700, David Pope wrote:
> > On Friday, December 2, 2011 4:41:58 PM UTC-5, Matt Mackall wrote:
> > >
> > > On Thu, 2011-12-01 at 17:38 -0500, Chuck Kirschman wrote:
> > > > # HG changeset patch
> > > > # User Chuck.Kirschman
> > > > # Date 1322778699 18000
> > > > # Branch stable
> > > > # Node ID 6f36523ce8fc00d836770a1a0f481df0ed27983f
> > > > # Parent  351a9292e430e35766c552066ed3e87c557b803b
> > > > enable sspi for windows
> > > > This patch will add SSPI capabilities for both normal http and
> > > ui.usehttp2=true
> > > > configurations of Mercurial on Windows. The check for the
> > > > authorization
> > > failure
> > > > has to happen at the point of opening the connection and resolved
> > > > at
> > > that time.
> >
> > I'm hoping Sune or Henrik can comment on this as they've already done
> > > some work in this area. I suspect we may want to put some of this
> in
> > > an extension. I understand there are issues here with keeping
> > > persistent connections that we might want to tackle on their own
> > > first (ie there's too much stuff for one patch here).
> > >
> > Hello all,
> >
> > Have the Windows volunteers (Sune, Henrik, ...?) had a chance to look
> > at this, or further their own work in the area?
> 
> Not that I know of.
> 
> >   I and my company are keenly
> > interested in having SSPI built into Mercurial.  We don't want to
> risk
> > having developers put their domain passwords in their hgrc files, and
> > our current VCS supports SSPI out-of-the-box so it's one more hurdle
> > for the switchover.  Keyring feels like a band-aid and doesn't help
> > our credibility when advocating the switch.
> 
> > I saw the recent discussion about the volunteer nature of Mercurial
> > development, which makes perfect sense.  If bodies are needed for
> > testing or developing, I'd be happy to help.  I've done some minor
> > SSPI-related development in the deep murky past, although I doubt
> > that's what's needed here.
> 
> Your best bet is to pester Chuck into posting his patch again, giving
> it a spin, and giving feedback. Until then, not much is likely to
> happen.
> 
> > (PS, I'm posting using Google Groups despite advice to the contrary,
> > since otherwise I would have had to manually create something
> > approximating a quoted reply (since I just joined the list).  The bad
> > things mentioned in "list etiquette" don't seem to have happened;
> > crossing my fingers...)
> 
> Unsuccessful.
> 
> --
> Mathematics is the supreme nostalgia of our time.
> 
> 
SSPI is definitely the way to go.  Aaron Jenson wrote a nice wiki page about getting Hg working on Windows, and a large portion of it is dedicated to get Basic Authentication to work, which is a lot of work and very seldom what anyone wants.  

Additional testing would be great.  We’ve been running it here for over 3 years (first submitted here:  http://www.selenic.com/pipermail/mercurial-devel/2009-March/010673.html) and it works great in our environment and for several folks who have contacted us over the years, but I’m sure there are a lot of variants in the way that AD can be set up.  I could give you our version of Hg to try out, but it has a lot of other primarily-Windows changes such as dealing with the case-insensitive file system, using your AD name as the default for commits, finding Beyond Compare in the registry, and so on. Thus it would not be a test of just this portion of code.  If you can apply this patch (or the new one when I get it posted again) to a clean source tree and try it that way it would be a better test.

I'll be happy to post the patch again as time permits. I can probably figure out how to make an extension out of it, although I really think it has to be enabled out-of-the-box on Windows which is why it was directly bolted in. However, I don't know anything about the other persistent connection problems nor how long this patch will have to wait for them to be solved first.