From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: sunsetting md5 password support
Date: Thu, 10 Oct 2024 18:28:26 -0400
Message-ID: <2735114.1728599306@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, hlinnaka@iki.fi, nathandbossart@gmail.com
Subject: Re: sunsetting md5 password support
In-Reply-To: <2735114.1728599306@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox