On Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote:
>>> However, that doesn't change that some people would like us to
>>> GSSAPI, and there may be some benefit (additional applications,
>>> network authentication, etc.) for doing so. If we can get
>>> programmers to code the support (i.e. Sun, JPL) I don't see any
>>> not to support the *additional* authentication methods.
>> Well, as I said already, a lot depends on the size of the patch.
>> As a reductio ad absurdum, if they drop 100K lines of code on us,
>> it *will* get rejected, no matter how cool it is.
> Oh, absolutely.
>> The current Kerberos support seems to require about 50 lines in
>> configure.in and circa 200 lines of C code in each of the backend
>> and libpq. Plus a dependency on an outside library that happens to
>> be readily available and compatibly licensed.
> I would expect, without looking at the details of the API, GSSAPI
> to be
> about the same amount of code if not less.
Probably save some Kerberos bookkeeping. Probably loose it with
GSSAPI bookkeeping, including name translation (which is far less
obvious). Net, I would expect to lose, but not by very much.
>> What amount of code are we talking about adding here, and what
>> dependencies exactly? What portability and license hazards will be
> The Kerberos5 libraries that we rely on today provide GSSAPI. So it
> would work with the same external library. Now, it could *also* work
> with other libraries in some cases (for example, the Win32 SSPI
> libraries), but with the same libraries it should work fine.
If I had a lot of time to spend on this I would write a SASL-like
wrapper so it could be used on platforms with GSSAPI, but not SASL
support in the OS. As you may have noticed, I believe SASL is the
way to go. I'm not up for it though.
There's probably room in the world for a "SASL-lite" library though.
Cyrus is great, but if your OS doesn't supply it for you, it's
supposed to be really hard to build.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2006-09-29 16:14:11|
|Subject: Array assignment behavior (was Re: Stored procedure array limits)|
|Previous:||From: Tom Lane||Date: 2006-09-29 15:57:39|
|Subject: Re: Block B-Tree concept |