Re: sunsetting md5 password support

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