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
mechanisms.
- 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.
Thoughts?
--
Michael
