On Thu, Jun 9, 2022 at 4:30 PM Jacob Champion <jchamp...@timescale.com> wrote:
> On Wed, Jun 8, 2022 at 9:58 PM Michael Paquier <mich...@paquier.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.
