[PATCH] support SSPI for Windows

David Pope d.e.pope at gmail.com
Mon Apr 16 10:20:45 CDT 2012


On Mon, Apr 16, 2012 at 9:26 AM,  <Chuck.Kirschman at bentley.com> wrote:
> 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.

Ours is a plain-vanilla AD setup, but I think if Mercurial covered the
90% case it would be perfectly fine as a first step.

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

Agreed.  I'll see if the existing patch applies cleanly to the current
tree and respond with results.  I'm guessing single-issue patchsets
are most likely to receive positive attention.

> 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,

I haven't worked with the hg devs, but given that 1) there are plenty
of folks who will never need the functionality, 2) isolation is good,
and 3) there's a pattern of "promoting" useful extensions to be
included in the official distribution, I think an extension would be
the way to go.  Hg devs please weigh in to teach the new guy (me) how
it's done around here.  :)

> although I really think it
> has to be enabled out-of-the-box on Windows which is why it was directly
> bolted in.

Enabling it out-of-the-box probably isn't the right path, although
that's certainly a policy decision to be made by the hg devs.  Hackers
working at home on open-source projects have no use for it, and
they're probably the larger audience for the foreseeable future.  Of
course, once SSPI is in place I could easily see hg dramatically
increasing its corporate usage and support...

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

Yes, can those who know what the issues are save us some re-learning
and explain the issues as they're currently understood?

On to implementation:  This is the entire kerberos extension:

    import urllib2_kerberos as u2k
    import mercurial.url

    def uisetup(ui):
        mercurial.url.opener_ = mercurial.url.opener

        def opener(*args, **kwargs):
            urlopener = mercurial.url.opener_(*args, **kwargs)
            urlopener.add_handler(u2k.HTTPKerberosAuthHandler())
            return urlopener

        mercurial.url.opener = opener

Do you think something similar would work, with your handlers in place
of urllib2_kerberos.HTTPKerberosAuthHandler?  Just an idea, I haven't
looked closely to see how well they match up.

Other things to think about:
- What does the [auth] configuration look like?  It should be illegal
to set a username.
- What would be involved with supporting SSPI for 'hg serve'?

----
David Pope


More information about the Mercurial-devel mailing list