On Wed, Jun 22, 2022 at 5:56 PM David G. Johnston
<david.g.johns...@gmail.com> wrote:
> 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"
I think that's a fair point, and your --auth-try example definitely
illustrates why having require_auth try to do everything is probably
not a viable strategy. My arguments for keeping OR in spite of that
are
- the default is effectively an OR of all available methods (plus "none");
- I think NOT is a important case in practice, which is effectively a
negative OR ("anything but this/these"); and
- not providing an explicit, positive OR to complement the above seems
like it would be a frustrating user experience once you want to get
just a little bit more creative.
It's also low-hanging fruit that doesn't require multiple connections
to the server per attempt (which I think your --auth-try proposal
might, if I understand it correctly).
> 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).
I think the newest tests in v3 should enforce that, but let me know if
I've missed something.
--Jacob
