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
- since-v2.diff.txt (text/plain)
- v3-0001-auth-generalize-SASL-mechanisms.patch (text/x-patch) patch v3-0001
- v3-0002-auth-pull-backend-SASL-exchange-into-its-own-file.patch (text/x-patch) patch v3-0002
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
-
Install properly fe-auth-sasl.h
- 6c9c28316683 15.0 landed
-
Add more sanity checks in SASL exchanges
- 44bd0126c70b 15.0 landed
-
Refactor SASL code with a generic interface for its mechanisms
- 9fd85570d179 15.0 landed