From: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sunsetting md5 password support |
Date: | 2024-10-10 12:27:04 |
Message-ID: | ZwfIGOW0kNpA6hke@sciurus.exwg.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
## Heikki Linnakangas (hlinnaka(at)iki(dot)fi):
> 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.
Password hashes are only in the "globals" dump (pg_dumpall -r/-g),
not in standard pg_dump (and I don't see anything about passwords
in the binary-upgrade mode of pg_dump).
Finally it might be a good thing that we separated data and roles.
Maybe that even is a plan for pg_upgrade: understand md5-password
when they appear in pg_authid, but do not apply special treatment
in CREATE ROLE/ALTER ROLE, thus preventing the setting of md5
password as pre-hashed passwords.
Regards,
Christoph
--
Spare Space.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2024-10-10 12:40:18 | Re: sunsetting md5 password support |
Previous Message | Ashutosh Bapat | 2024-10-10 12:06:10 | Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning |