Re: Add "password_protocol" connection parameter to libpq

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add "password_protocol" connection parameter to libpq
Date: 2019-08-13 22:25:06
Message-ID: c57b140decb72a8b5a845a33a23dbc0bcee6c111.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2019-08-13 at 16:51 -0400, Jonathan S. Katz wrote:
> Alternatively, we could combine 2 & 3, e.g.:
>
> channel_binding = {disable|prefer|require}
>
> # comma-separated list of protocols that are ok to the user, remove
> # ones you don't want. empty means all is ok
> password_protocol = "plaintext,md5,scram-sha-256,scram-sha-256-
> plus"

I still feel like lists are over-specifying things. Let me step back
and offer an MVP of a single new parameter:

channel_binding={prefer|require}

And has a lot of benefits:
* solves the immediate need to make channel binding useful, which
is a really nice feature
* compatible with most of the other proposals we're considering, so
we can always extend it when we have a better understanding and
consensus
* clear purpose for the user
* doesn't introduce new concepts that might be confusing to the
user, like SASL or the use of "-plus" to mean "with channel binding"
* guides users toward the good practice of using SSL and SCRAM
* simple to implement

The other use cases are less clear to me, and seem less urgent.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Dubé 2019-08-13 22:43:21 12's AND CHAIN doesn't chain when transaction raised an error
Previous Message Jonathan S. Katz 2019-08-13 20:51:57 Re: Add "password_protocol" connection parameter to libpq