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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jacob Champion <pchampion(at)vmware(dot)com>
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-07-08 07:27:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Jul 07, 2021 at 03:07:14PM +0000, Jacob Champion wrote:
> That's correct. But the client may not simply ignore the challenge and
> keep the exchange open waiting for a new one, as pg_SASL_continue()
> currently allows. That's what my TODO is referring to.

I have been looking more at your three points from upthread and
feasted on the SASL RFC, as of:
- Detection that no output is generated on PG_SASL_EXCHANGE_FAILURE
for the backend.
- Handling of zero-length messages in the frontend. The backend
handles that already, and SCRAM would complain if sending such
messages, but I can see why you'd want to allow that for other
- Making sure that a mechanism generates a message in the middle of
the exchange in the frontend.

I agree that this looks like an improvement in terms of the
expectations behind a SASL mechanism, so I have done the attached to
strengthen a bit all those checks. However, I don't really see a
point in back-patching any of that, as SCRAM satisfies with its
implementation already all those conditions AFAIK. So that's an
improvement of the current code, and it fits nicely with the SASL
refactoring for the documentation of the callbacks.


Attachment Content-Type Size
sasl-checks.patch text/x-diff 2.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-07-08 07:37:12 Re: A few assorted typos in comments
Previous Message 2021-07-08 06:54:45 Failed transaction statistics to measure the logical replication progress