Horton

Re: [PoC] Let libpq reject unexpected authentication requests

Jacob Champion <jchampion@timescale.com>

View thread View on postgr.es
From: Jacob Champion <jchampion@timescale.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Michael Paquier <michael@paquier.xyz>, "David G. Johnston" <david.g.johnston@gmail.com>
Date: 2022-10-20T18:36:34Z
Lists: pgsql-hackers

Attachments

On Wed, Oct 12, 2022 at 9:40 AM Jacob Champion <jchampion@timescale.com> wrote:
> On 10/5/22 06:33, Peter Eisentraut wrote:
> > I think it would be good to put some provisions in place here, even if
> > they are elementary.  Otherwise, there will be a significant burden on
> > the person who implements the next SASL method (i.e., you ;-) ) to
> > figure that out then.
>
> Sounds good, I'll work on that. v10 does not yet make changes in this area.

v11 makes an attempt at this (see 0003), using the proposed string list.

Personally I'm not happy with the amount of complexity it adds in
exchange for flexibility we can't use yet. Maybe there's a way to
simplify it, but I think the two-tiered approach of the patch has to
remain, unless we find a way to move SASL mechanism selection to a
different part of the code. I'm not sure that'd be helpful.

Maybe I should just add a basic Assert here, to trip if someone adds a
new SASL mechanism, and point that lucky person to this thread with a
comment?

--Jacob

Commits

  1. libpq: Add sslcertmode option to control client certificates

  2. Rewrite error message related to sslmode in libpq

  3. libpq: Add support for require_auth to control authorized auth methods

  4. Run pgindent on libpq's fe-auth.c, fe-auth-scram.c and fe-connect.c