From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sunsetting md5 password support |
Date: | 2024-10-10 12:40:18 |
Message-ID: | 76396e05-0724-4b17-9194-2875df40feb8@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-10-09 We 7:11 PM, Heikki Linnakangas wrote:
> On 09/10/2024 22:55, Nathan Bossart wrote:
>> In this message, I propose a multi-year, incremental approach to
>> remove MD5
>> password support from Postgres.
>
> +1
>
>> 2. In v19, allow upgrading with MD5 passwords and allow
>> authenticating
>> with them, but disallow creating new ones (i.e., restrict/remove
>> password_encryption and don't allow setting pre-hashed MD5
>> passwords).
>
> This is a bit weird state. What exactly is "upgrading"? I guess you
> mean pg_upgrade, but lots of people use pg_dump & restore or logical
> replication or something else entirely for upgrading. That's
> indistinguishable from setting a pre-hashed MD5 password.
>
> I think it's bad if you cannot pg_dump & restore your database.
Hmm, yeah. It would be easy enough to prevent MD5 passwords in things
like CREATE ROLE / ALTER ROLE, but harder to check for MD5 if there are
direct updates to pg_authid. Maybe we need to teach pg_dumpall a way to
do that as a workaround?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-10-10 12:43:32 | Re: On disable_cost |
Previous Message | Christoph Moench-Tegeder | 2024-10-10 12:27:04 | Re: sunsetting md5 password support |