From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pg14, pg_dumpall and "password_encryption=true" |
Date: | 2021-03-03 17:17:28 |
Message-ID: | f2930c17-767f-89db-bd00-aa8fe31e21a3@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18.01.21 07:18, Michael Paquier wrote:
>> This would be interpreting setconfig='{password_encryption=on}' as "opt out of
>> future password security increases". I expect that will tend not to match the
>> intent of the person entering the setting. That said, if v14 were already
>> behaving this way, I wouldn't dislike it enough to complain.
> Hm. Up to 13, "on" is a synonym of "md5", so it seems to me
> that we should map "on" to "md5" rather than "scram-sha-256" on the
> side of compatibility. But you have a point when it comes to good
> security practices. It makes me wonder whether it would be better to
> have pg_dumpall complain rather than pg_upgrade if this value is found
> in the proconfig items.. pg_upgrade is not the only upgrade path
> supported.
This is registered in the commit fest, but there is no actual patch
proposed.
I don't think it's worth doing anything about this. Right now, you get
a clear error message, and then you can decide what to do about it.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-03-03 17:21:21 | Re: [PATCH] Add --create-only option to pg_dump/pg_dumpall |
Previous Message | Robert Haas | 2021-03-03 17:15:49 | Re: pg_amcheck contrib application |