SASL, compression? - Mailing list pgsql-hackers

I've been looking at the authentication and networking code and
would like to float a trial balloon.

1) add SASL.  This is a new standards-track protocol that is often  described as "PAM" for network authentication.
PostgreSQLcould  remove *all* protocol-specific authentication code and use  standard plug-in libraries instead.
 
  (It's worth noting that SSL/TLS operates at a lower level than  SASL.  This has some interesting consequences, see
below.)
  After the black-box authentication finishes, the postmaster will  have up to pieces of information: the peer's client
cert(SSL)  and a string containing the Kerberos principal, user name verified  with password/one-time-password/CRAM,
etc.
  PostgreSQL authentication would be reduced to specifying which  authentication methods are acceptable for each
database,then  mapping that authenticated user string and/or cert to a pguser.
 

2) add ZLIB compression.

The last point needs a bit of explanation.  With SASL, the buffers
may be modified due to the authentication protocol selected, so the
low-level routines in pqcomm.c and fe-connect.c must be modified.
But since this is happening anyway, it would be easy to wrap
sasl_encode with ZLIB compression and sasl_decode with ZLIB decompression,
with pq_flush() (and client's equivalent) doing a "sync flush" of
the compression buffer.

You obviously don't need compression on the Unix socket or a fast
network connection, but if you're on a T1 or slower the reduced
transmission time should more than offset the time spent in 
compression/decompression.

Drawbacks

The biggest drawback, at least initially, is that the initial
exchange will need to be totally rewritten.  One possibility
could use something like this:
 S: 220 example.com PostgreSQL 8.1 C: HELO client.com S: 250-example.com S: 250-AUTH ANONYMOUS KERBEROS4         <list
ofauthentication methods> S: 250-STARTTLS                         <server accepts SSL/TLS> S: 250-COMPRESSION
          <compress datastream> S: 250 HELP C: STARTTLS pq.virtual.com              <allows virtual domains>
<SSL/TLSnegotation occurs *here*> S: 250-pq.virtual.com S: 250-AUTH ANONYMOUS PLAIN KERBEROS4   <note extra method> S:
250-COMPRESSIONS: 250-some extract functions only available with TLS/SSL sessions S: 250 HELP C: AUTH PLAIN user
password            <use simple username/password> S: 220 OK C: COMPRESSION ON S: 220 OK C: OPEN database S: 220 OK
 

and then the system drops back to the existing data exchange
format.  Or it could look like something entirely different - the
most important thing is that the server needs to provide a list
of authentication methods, the client chooses one, and it either
succeeds or the client can retry.  However a protocol something
like this has the strong advantage of being well-tested in the 
existing protocols.

Bear