From: | "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Magnus Hagander" <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: JAVA Support |
Date: | 2006-09-28 22:46:57 |
Message-ID: | C21B76CD-EA83-4A37-910B-12994EDB8AC4@jpl.nasa.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sep 28, 2006, at 2:24 PM, Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> As for the other part - will core accept this - I can't answer that.
>
> It would depend in part on the size of the patch, and on whether there
> are any arguments for supporting GSSAPI besides "Java can't do
> Kerberos".
> What would it buy for a libpq user?
Everything that the current Kerberos support provides plus Java.
Ability to encrypt or integrity protect the client/server connection
(without SSL/TLS tunnels).
In theory, you get to plug in other mechanisms than Kerberos. In
practice I think this only worked on Solaris, until very recently.
The free gssapi implementations in Java, Solaris, MIT Kerberos, and
Heimdal Kerberos only supported Kerberos. Sun open sourced their
mechanism glue code and it's being incorporated into both MIT (now)
and Heimdal (0.8). Entrust sells a PKI mechanism for Solaris.
Wire compatibility with a native Windows API (the SSPI), if it's used
correctly. (Google for posts by Jeffrey Altman for references to
example code.)
------------------------------------------------------------------------
----
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
From | Date | Subject | |
---|---|---|---|
Next Message | Henry B. Hotz | 2006-09-28 22:58:52 | Re: JAVA Support |
Previous Message | Gevik Babakhani | 2006-09-28 22:28:55 | Re: Row IS NULL question |