Re: [PATCH] Pull general SASL framework out of SCRAM

Jacob Champion <pchampion@vmware.com>

From: Jacob Champion <pchampion@vmware.com>
To: "michael@paquier.xyz" <michael@paquier.xyz>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-06-30T22:30:12Z
Lists: pgsql-hackers

Attachments

On Sat, 2021-06-26 at 09:47 +0900, Michael Paquier wrote:
> On Fri, Jun 25, 2021 at 11:40:33PM +0000, Jacob Champion wrote:
> > I can definitely move it (into, say, auth-sasl.c?). I'll probably do
> > that in a second commit, though, since keeping it in place during the
> > refactor makes the review easier IMO.
> 
> auth-sasl.c is a name consistent with the existing practice.
> 
> > Can do. Does libpq-int-sasl.h work as a filename? This should not be
> > exported to applications.
> 
> I would still with the existing naming used by fe-gssapi-common.h, so
> that would be fe-auth-sasl.c and fe-auth-sasl.h, with the header
> remaining internal.  Not strongly wedded to this name, of course, that
> just seems consistent.

Done in v3, with a second patch for the code motion.

I added a first pass at API documentation as well. This exposed some
additional front-end TODOs that I added inline, but they should
probably be dealt with independently of the refactor:

- Zero-length client responses are legal in the SASL framework;
currently we use zero as a sentinel for "don't send a response".

- I don't think it's legal for a client to refuse a challenge from the
server without aborting the exchange, so we should probably check to
make sure that client responses are non-NULL in the success case.

--Jacob

Commits

  1. Install properly fe-auth-sasl.h

  2. Add more sanity checks in SASL exchanges

  3. Refactor SASL code with a generic interface for its mechanisms