On Fri, 2019-08-09 at 16:27 -0400, Jonathan S. Katz wrote:
> Seems to be a lot to configure. I'm more of a fan of the previous
> method; it'd work nicely with how we've presently defined things and
> should be easy to put into a DSN/URI/env variable.
Proposals on the table:
1. Hierarchical semantics, where you specify the least-secure
acceptable method:
password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
2. Comma-list approach, where you specify exactly which protocols are
acceptable, or "any" to mean that we don't care.
3. three-setting approach:
channel_binding = {disable|prefer|require}
password_plaintext = {disable|enable}
password_md5 = {disable|enable}
It looks like Jonathan prefers #1.
#1 seems direct and clearly applies today, and corresponds to auth
methods on the server side.
I'm not a fan of #2, it seems likely to result in a bunch of clients
with overly-specific lists of things with long names that can never
really go away.
#3 is a little more abstract, but also seems more future-proof, and may
tie in to what Stephen is talking about with respect to controlling
auth methods from the client, or moving more protocols within SASL.
Regards,
Jeff Davis