On 2024-10-10 Th 6:28 PM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
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?
That seems like a pretty awful idea. Having dump scripts that
perform direct updates on pg_authid would lock us into supporting
the current physical representation (ie that pg_authid is in fact
a table with such-and-such columns) forever. Not to mention that
no such script could be restored with anything less than full
superuser privileges. And in return we're getting what exactly?
Well, I think if we keep a sort of half way house where we continue to
allow existing md5 passwords we'd have to do some ugly things. So ...
On the whole I agree with Heikki's comment that we should just
do it (disallow MD5, full stop) whenever we feel that enough
time has passed. These intermediate states are mostly going to
add headaches. Maybe we could do something with an intermediate
release that just emits warnings, without any feature changes.
I also agree with this.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com