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

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

In response to

Responses

Browse pgsql-hackers by date

  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