Re: SSPI authentication

Stephen Frost wrote:
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> Stephen Frost wrote:
>>> If both are made available then I think that'd work fine for us. I'm
>>> concerned that the windows builds wouldn't include a version of libpq w/
>>> GSSAPI...
>> The default build wouldn't. The binary build wouldn't. If you by GSSAPI
>> mean MIT linking - SSPI does GSSAPI *authentication* just fine.
>
> I don't think SSPI supports having seperate credential caches, a
> different default realm, etc...
> (and I'm not sure how you'd set them up even if it did).

No, it does not. But that in itself has nothing to do with GSSAPI - your
requirement is something different. That's not saying we should ignore
your requirement :-)

>> One reason is that bringing in and configuring the MIT libraries is a
>> significant overhead.
>
> Erm, isn't this what's done now?

Except you don't need to configure it unless you use it, but yes, it's
an overhead we have now. That I would very much like to get rid of.

> Are we actually overloaded in some way
> on the buildds? Would this actually be a measurable reduction in the
> overhead of the buildds? I find this argument less than convincing
> reasoning for dropping existing functionality...

Yes. It's a pain to get the kerberos stuff set up :-(

>> Nothing would prevent you from building your own DLL with Kerberos linking.
>
> Except when it breaks because it's not being tested in the build
> system... :/ I expect there are other such things in the same situation
> but I'm rather unhappy that it's something which is actually going to
> impact people (at the least me) as opposed to GNU readline on some
> esoteric architecture.

Say what?
You'd still get them tested on any BF member that configures it. Just
like now - you won't get it tested unless the BF member is specifically
configured to get it. The only difference is that the SSPI code *would*
get tested even if you don't specifically configure it.

We can easily make sure that at we have BF coverage of the feature. It's
also the same codepath that would be used on Unix, so you'd get that
coverage as well - not complete, but a good part of the way.

>>> If I was confident that we could easily build it ourselves
>>> then I wouldn't care as much but, since I've never had to build libpq on
>>> Windows before, I'm not sure what effort is involved or what tools are
>>> required. I'm also not thrilled by the prospect. :)
>> It's not hard, at least if you use MSVC to build it. It's harder with
>> MingW, but far from impossible.
>
> MSVC would be a rather unhappy requirement.

Why? But again, you can do mingw if you want to.

> Do we have buildds running
> with MingW? Settings up buildds is documented, etc, no? I don't know
> if I could dedicate a machine to it but at least if I can build my own
> buildd setup using the scripts and whatnot it might not be too bad..

I have no idea even what buildds is, so I can't comment on if it works
with mingw :-)

>>> I have to admit that this does kind of make
>>> me wish a bit for a 'libpq config file' even though I'm generally against
>>> such things. Having the same easy switch as we do w/ Mozilla would be
>>> really nice.
>> So what we'd need in that case is a new libpq connectionstring
>> parameter. Which can be done, but it'd require that all frontends that
>> use libpq add support for it - such as pgadmin. I'm not sure if the ODBC
>> driver will support arbitrary arguments, otherwise that one needs it too.
>
> If the ODBC driver doesn't support changes to the connectionstring (and
> I think it does, actually), that'd probably be a sensible thing to add
> anyway. Having to have what's essentially a library-config option
> handled by all the clients does kind of suck though.

The only other option I can think of is an environment variable, which
seems very un-windowsy. But we could have something like "sent
environment variable PG_GSSAPI=mit" and then attempt to dynamically load
the kerberos libraries. Specifically for win32. It's a bit of a kludge,
and it'll certainly add more code, but it's not *hard* to do.

It will keep the overhead for the builder of the distribution (hello,
Dave) since it will still require the headers to be present on the build
machine, but not for end-users that don't want it (assuming we stop
shipping the MIT DLLs in the package, which I'd like to do).

Also, remember that there is no actual testing of it on the BF. We
don't test the functionality today on the BF, but at least we detect
link-time errors ;-)

>> As I'm sure you can tell, I'm far from convinced this is a good idea ;-)
>
> It's also not exactly unheard of. I'm pretty sure what mozilla does is
> basically just dlopen() the appropriate library. I'm not sure if it's
> even got an internal set of dlls which link to the sspi/gssapi dlls
> explicitly. If it does we might be able to swipe it. Sorry for my lack
> of familiarity, but does SSPI provide a GSSAPI identical to the MIT one?

GSSAPI protocol, yes.
GSSAPI API, no.

> For some reason I was thinking it did (hence why the dll magic just
> works, but there could be more going on in those possibly) in which case
> I'm not even sure you'd need the MIT stuff available to compile with
> support for it?

You don't need it to do GSSAPI authentication, no.
You do need it if you need to do non-windows GSSAPI authentication. Such
as your case when you want to authenticate to a realm that your windows
system is not a part of.

>> Anybody else want to comment on this?
>
> I've always been rather unhappy at the apparent lack of user participation
> on this list. :/ I don't mean to imply that I speak for the silent
> majority, just that it's frustrating when trying to gauge the impact
> of changes.

Yeah, that is a problem... I can only speak for my self and those that I
have worked with/talked to, and you are the first one I've heard of that
actually *prefers* using the MIT libraries if there's another option
available on Windows. So it's good that you do speak up :)

//Magnus