From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Pull general SASL framework out of SCRAM |
Date: | 2021-06-30 22:30:12 |
Message-ID: | 0907fda41fb40b23e2cbdf7eb05a8d61dd5307b3.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
since-v2.diff.txt | text/plain | 25.4 KB |
v3-0001-auth-generalize-SASL-mechanisms.patch | text/x-patch | 27.4 KB |
v3-0002-auth-pull-backend-SASL-exchange-into-its-own-file.patch | text/x-patch | 15.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2021-06-30 22:41:01 | Re: Preventing abort() and exit() calls in libpq |
Previous Message | Tom Lane | 2021-06-30 22:29:11 | Re: Preventing abort() and exit() calls in libpq |