Re: JAVA Support
Henry B. Hotz <hotz@jpl.nasa.gov>
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
To: "Magnus Hagander" <mha@sollentuna.net>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Josh Berkus" <josh@agliodbs.com>, "Kris Jurka" <books@ejurka.com>, <pgsql-hackers@postgresql.org>
Date: 2006-09-29T16:01:32Z
Lists: pgsql-hackers
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. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu