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
signature.asc
Description: PGP signature
