Re: sunsetting md5 password support
От | Andrew Dunstan |
---|---|
Тема | Re: sunsetting md5 password support |
Дата | |
Msg-id | 76396e05-0724-4b17-9194-2875df40feb8@dunslane.net обсуждение исходный текст |
Ответ на | Re: sunsetting md5 password support (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: sunsetting md5 password support
|
Список | 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
В списке pgsql-hackers по дате отправления: