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 <>. 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...


The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to