On 2024-10-10 Th 6:28 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@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
