From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add "password_protocol" connection parameter to libpq |
Date: | 2019-08-09 21:56:28 |
Message-ID: | daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-08-09 22:35:20 | Re: POC: converting Lists into arrays |
Previous Message | Heikki Linnakangas | 2019-08-09 21:17:50 | Re: Add "password_protocol" connection parameter to libpq |