From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: scram and \password |
Date: | 2017-03-14 00:54:48 |
Message-ID: | e6175f95-db59-531b-d345-52069b3c941a@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
> 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
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-03-14 00:58:28 | Re: Partition-wise join for join between (declaratively) partitioned tables |
Previous Message | Michael Paquier | 2017-03-14 00:51:54 | Re: Should buffer of initialization fork have a BM_PERMANENT flag |