Re: Pg14, pg_dumpall and "password_encryption=true"

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.

In response to

Browse pgsql-hackers by date

  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