| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, samay sharma <smilingsamay(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Proposal: Support custom authentication methods using hooks |
| Date: | 2022-03-02 08:24:26 |
| Message-ID: | 684c9d5b-2ab4-0546-4520-8e49a49ad1fb@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01.03.22 22:17, Jonathan S. Katz wrote:
> If you're moving to a newer version of PostgreSQL, you likely have to
> update your connection drivers anyway (rebuilt against new libpq,
> supporting any changes in the protocol, etc). I would prefer more data
> to support that argument, but this is generally what you need to do.
>
> However, we may need to step towards it. We took one step last release
> with defaulting to SCRAM. Perhaps this release we add a warning for
> anything using md5 auth that "this will be removed in a future release."
> (or specifically v16). We should also indicate in the docs that md5 is
> deprecated and will be removed.
I find that a lot of people are still purposely using md5. Removing it
now or in a year would be quite a disruption.
It's also worth considering that keeping the code equipped to handle
different kinds of password hashing would help it stay in shape if we
ever need to add support for the next SHA after 256 or whatever.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shiy.fnst@fujitsu.com | 2022-03-02 08:28:34 | RE: Failed transaction statistics to measure the logical replication progress |
| Previous Message | Kyotaro Horiguchi | 2022-03-02 08:22:35 | Re: pg_stop_backup() v2 incorrectly marked as proretset |