On Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote:
However, that doesn't change that some people would like us to
support
GSSAPI, and there may be some benefit (additional applications,
better
network authentication, etc.) for doing so. If we can get
additional
programmers to code the support (i.e. Sun, JPL) I don't see any
reason
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
added?
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.
//Magnus
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.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
