Re: Proposal: Support custom authentication methods using hooks
От | Jonathan S. Katz |
---|---|
Тема | Re: Proposal: Support custom authentication methods using hooks |
Дата | |
Msg-id | 115918cb-6009-3fac-712d-8d1eee3bb1a6@postgresql.org обсуждение исходный текст |
Ответ на | Re: Proposal: Support custom authentication methods using hooks (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Proposal: Support custom authentication methods using hooks
Re: Proposal: Support custom authentication methods using hooks |
Список | pgsql-hackers |
On 3/2/22 3:24 AM, Peter Eisentraut wrote: > 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. What are the reasons they are still purposely using it? The ones I have seen/heard are: - Using an older driver - On a pre-v10 PG - Unaware of SCRAM What I'm proposing above is to start the process of deprecating it as an auth method, which also allows to continue the education efforts to upgrae. Does that make sense? > 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. I think it's fine to keep the hashing code. The end goal is to remove the md5 authentication mechanism. Thanks, Jonathan
Вложения
В списке pgsql-hackers по дате отправления: