Re: SASL, compression? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: SASL, compression?
Date
Msg-id 200206070524.g575OXe20465@candle.pha.pa.us
Whole thread Raw
In response to Re: SASL, compression?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bear Giles <bgiles@coyotesong.com> writes:
> > 1) add SASL.  This is a new standards-track protocol that is often
> >    described as "PAM" for network authentication.  PostgreSQL could
> >    remove *all* protocol-specific authentication code and use
> >    standard plug-in libraries instead.
> 
> To me, "new standards-track protocol" translates as "pie in the sky".
> When will there be tested, portable, BSD-license libraries that we
> could *actually* use?  I'm afraid this really would end up meaning
> writing and/or supporting our own SASL code ... and I think there
> are more important things for the project to be doing.
> 
> IMHO we've got more than enough poorly-supported authentication options
> already.  Unless you can make a credible case that using SASL would
> allow us to rip out PAM, Kerberos, MD5, etc *now* (not "in a few releases
> when everyone's switched to SASL"), I think this will end up just being
> another one :-(.
> 
> (It doesn't help any that PAM support was sold to us just one release
> cycle back on the same grounds that it'd be the last authentication
> method we'd need to add.  I'm more than a tad wary now...)

I agree with Tom on this one.  "Plugin" sounds so slick, but it really
translates to "abstraction", and as if our authentication stuff isn't
already confusing enough for users to configure, we add another level of
abstraction into the mix, and things become even more confusing.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: revised sample SRF C function; proposed SRF API
Next
From: Bruce Momjian
Date:
Subject: Re: Use of /etc/services?