On Wed, Mar 02, 2022 at 11:15:28AM -0500, Stephen Frost wrote:
> With... which? We removed recovery.conf without any warning between
> major releases, yet it was used by every single PG file-based backup and
> restore solution out there and by every single organization that had
> ever done a restore of PG since it was introduced in 8.0.
There was much more to the changes around recovery.conf, with the
integration of its parameters as GUCs so it had a lot of benefits,
and that's why it has baked for 3~4 years as far as I recall. There
is SCRAM as a replacement of MD5 already in core, but as Jonathan said
upthread the upgrade from an instance that still has MD5 hashes may
finish by being tricky for some users because this does not concern
only pg_upgrade (this could fail if it detects MD5 hashes in
pg_authid), and we don't really know how to solve the pg_dump bit, do
we? And it seems to me that this is not a matter of just blocking the
load of MD5 hashes in the backend in the case of logical dumps.
> Passing
> around cleartext passwords with the LDAP authentication method is
> clearly bad from a security perspective and it's a bunch of code to
> support that, along with it being quite complicated to configure and get
> set up (arguably harder than Kerberos, if you want my 2c). If you want
> to say that it's valuable for us to continue to maintain that code
> because it's good and useful and might even be the only option for some
> people, fine, though I disagree, but I don't think my argument that we
> shouldn't keep it just because *someone* is using it is any different
> from our general project policy about features.
MD5 is still used at auth method by many people, as is LDAP. They
have their design flaws (backend LDAP, MD5 hashes in old backups), but
those code areas are pretty mature as well, so a simple removal could
hurt the user base of PG quite a lot IMO.
--
Michael