From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        Nathan Bossart <nathandbossart@gmail.com>,
        pgsql-hackers@postgresql.org
Subject: Re: sunsetting md5 password support
In-reply-to: <76396e05-0724-4b17-9194-2875df40feb8@dunslane.net>
References: <ZwbfpJJol7lDWajL@nathan>
 <7e9e3d30-f7f4-460f-a626-6cfad419d6cd@iki.fi>
 <76396e05-0724-4b17-9194-2875df40feb8@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Thu, 10 Oct 2024 08:40:18 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2735113.1728599306.1@sss.pgh.pa.us>
Date: Thu, 10 Oct 2024 18:28:26 -0400
Message-ID: <2735114.1728599306@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2735114.1728599306%40sss.pgh.pa.us>
Precedence: bulk

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?

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.

			regards, tom lane