Sent directly. Anyone else who's interested can have a copy. Just
email me.
I *think* it's structurally sound. Please tell me if you find a
problem. It lacks a lot: proper specification of required security
properties, a way to specify different mechanism lists for local,
vice TCP, vice SSL connections, authN name to authZ name mapping,
most seriously I didn't implement security layers. Lots of debug
checking still needed.
OTOH it works on MacOS 10.4 G4 client and Intel server.
As to the Postgres password database: If you use the DIGEST-MD5
mechanism, then you could get a secure, encrypted connection with no
setup except the PG password. Also it would have made it easier for
people to migrate from the current stuff to SASL.
SASL *could* do everything that *any* of the current auth methods can
do (OK, except ident) and then some. I thought that exporting all
that code and functionality to a standard library would be a good
thing in the long run. The down side is that completely replacing
the existing framework would require SASL libraries readily available
on *all* platforms that PG supports, and Windows doesn't. The
Windows SASL API's turn out to be only available on 2K3 server, and
have never been publicly tested for interoperability with the
standard Unix library.
I still believe in SASL. I know the Cyrus SASL library has become
pretty ubiquitous on Unix platforms. I wish there were a simpler C
API than Cyrus. Java 1.4.2 and up supports it. There are ways it
could be provided on Windows, but not within the level of effort that
Magnus or I can devote to the problem.
---------
For GSSAPI, there is published interop code for the Windows SSPI at
<http://web.mit.edu/jaltman/Public/kfw/gss/>. It's more places than
SASL is. Down side is it doesn't do much that the current Krb5 code
doesn't do.
Structurally the GSSAPI mods will be very similar to the SASL ones I
already did.
On Jan 26, 2007, at 7:16 PM, Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
If anyone is interested I currently have working-but-incomplete
patches to support SASL in C. I've decided not to finish and submit
them because the glue code to make configuration reasonable, and to
allow use of existing Postgres password databases with the password-
based mechanisms is still significant.
I'd certainly like to take a look at it. I'm not entirely sure I
follow
what you mean by 'allow use of existing Postgres password databases'-
I'm not sure SASL support requires that ability (after all, if they
want
to use the 'md5' or similar mechanism they can with the current
protocol). Or am I missing something about how the SASL
implementation
is done or intended to be used? I'd tend to think it'd mainly be used
as a mechanism to support other authentication mechanisms which don't
use the internal Postgres passwords...
Thanks,
Stephen
------------------------------------------------------------------------
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 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
