Re: [HACKERS] scram and \password - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] scram and \password
Date
Msg-id CAB7nPqRb5D4L4A1CAF+n82xQR1cy5EisW5cnPWOyLyEgke=sAg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Tue, Mar 14, 2017 at 9:54 AM, Joe Conway <mail@joeconway.com> wrote:
> On 03/12/2017 08:10 PM, Michael Paquier wrote:
>> OK, so what about doing the following then:
>> 1) Create pg_role_password_type(oid), taking a role OID in input and
>> returning the type.
>
> That version would make sense for administrative use. I still think we
> might want a version of this that takes no argument, works on the
> current_user, and is executable by anyone.

Sure.

>> 2) Extend PQencryptPassword with a method, and document. Plaintext is forbidden.
>
> Check, although if "plain" were allowed as a method for the sake of
> consistency/completeness the function could just immediately return the
> argument.
>
>> 3) Extend \password in psql with a similar -method=scram|md5 argument,
>> and forbid the use of "plain" format.
>
> Not sure why we would forbid "plain" here unless we remove it entirely
> elsewhere.

OK. I don't mind about those two, as long as documentation is clear
enough about what using plain leads to.

>> After thinking about it, extending PQencryptPassword() would lead to
>> future breakage, which makes it clear to not fall into the trap of
>> having password_encryption set to scram in the server's as well as in
>> pg_hba.conf and PQencryptPassword() enforcing things to md5.
>
> I'm not grokking this statement

To grok: "To understand profoundly through intuition or empathy.".
Learning a new thing everyday.
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Next
From: Corey Huinker
Date:
Subject: Re: [HACKERS] asynchronous execution