Re: [PoC] Let libpq reject unexpected authentication requests

On Thu, Jun 9, 2022 at 4:30 PM Jacob Champion <jchampion(at)timescale(dot)com>
wrote:

> On Wed, Jun 8, 2022 at 9:58 PM Michael Paquier <michael(at)paquier(dot)xyz>
> wrote:
>
> > One
> > interesting case comes down to stuff like channel_binding=require
> > require_auth="md5,scram-sha-256", where I think that we should still
> > fail even if the server asks for MD5 and enforce an equivalent of an
> > AND grammar through the parameters. This reasoning limits the
> > dependencies between each parameter and treats the areas where these
> > are checked independently, which is what check_expected_areq() does
> > for channel binding. So that's more robust at the end.
>
> Agreed.
>
>
That just makes me want to not implement OR'ing...

The existing set of individual parameters doesn't work as an API for
try-and-fallback.

Something like would be less problematic when it comes to setting multiple
related options:

--auth-try
"1;sslmode=require;channel_binding=require;method=scram-sha-256;sslcert=/tmp/machine.cert;sslkey=/tmp/machine.key"
--auth-try
"2;sslmode=require;method=cert;sslcert=/tmp/me.cert;sslkey=/tmp/me.key"
--auth-try "3;sslmode=prefer;method=md5"

Absent that radical idea, require_auth probably shouldn't change any
behavior that exists today without having specified require_auth and having
the chosen method happen anyway. So whatever happens today with an md5
password prompt while channel_binding is set to require (not in the mood
right now to figure out how to test that on a compiled against HEAD
instance).

David J.