On Thu, May 4, 2017 at 8:37 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 05/03/2017 08:40 PM, Tom Lane wrote:
>>
>> The other question I can think to ask is what will happen during
>> pg_upgrade, given an existing installation with one or more passwords
>> stored plain. If the answer is "silently convert to MD5", I'd be
>> good with that.
>
>
> Yes, it will silently convert to MD5. That happened even on earlier
> versions, if you had password_encryption=on in the new cluster (which was
> the default).
>
> I'm planning to go ahead with the attached patch for this (removing
> password_encryption='plain' support, but keeping the default as 'md5').
The patch attached does not apply on HEAD at 499ae5f, regression tests
are conflicting.
+ This option is obsolete but still accepted for backwards
+ compatibility.
Isn't that incorrect English? It seems to me that this be non-plural,
as "for backward compatibility".
The comment at the top of check_password() in passwordcheck.c does not
mention scram, you may want to update that.
+ /*
+ * We never store passwords in plaintext, so
this shouldn't
+ * happen.
+ */
break;
An error here is overthinking?
-- consistency of password entries
-SET password_encryption = 'plain';
-CREATE ROLE regress_passwd1 PASSWORD 'role_pwd1';
SET password_encryption = 'md5';
Nit: this is skipping directly to role number 2.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
