Skip site navigation (1) Skip section navigation (2)

Re: JAVA Support

From: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Kris Jurka" <books(at)ejurka(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JAVA Support
Date: 2006-09-29 16:01:32
Message-ID: (view raw, whole thread or download thread mbox)
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
>> 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(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 LaneDate: 2006-09-29 16:14:11
Subject: Array assignment behavior (was Re: Stored procedure array limits)
Previous:From: Tom LaneDate: 2006-09-29 15:57:39
Subject: Re: Block B-Tree concept

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group