Date: Thu, 10 Oct 2024 14:27:04 +0200
From: Christoph Moench-Tegeder <cmt@burggraben.net>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org
Subject: Re: sunsetting md5 password support
Message-ID: <ZwfIGOW0kNpA6hke@sciurus.exwg.net>
References: <ZwbfpJJol7lDWajL@nathan>
 <7e9e3d30-f7f4-460f-a626-6cfad419d6cd@iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7e9e3d30-f7f4-460f-a626-6cfad419d6cd@iki.fi>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/ZwfIGOW0kNpA6hke%40sciurus.exwg.net>
Precedence: bulk

## Heikki Linnakangas (hlinnaka@iki.fi):

> This is a bit weird state. What exactly is "upgrading"? I guess you
> mean pg_upgrade, but lots of people use pg_dump & restore or logical
> replication or something else entirely for upgrading. That's
> indistinguishable from setting a pre-hashed MD5 password.

Password hashes are only in the "globals" dump (pg_dumpall -r/-g),
not in standard pg_dump (and I don't see anything about passwords
in the binary-upgrade mode of pg_dump).
Finally it might be a good thing that we separated data and roles.
Maybe that even is a plan for pg_upgrade: understand md5-password
when they appear in pg_authid, but do not apply special treatment
in CREATE ROLE/ALTER ROLE, thus preventing the setting of md5
password as pre-hashed passwords.

Regards,
Christoph

-- 
Spare Space.