Re: WIP: SCRAM authentication
От | Robert Haas |
---|---|
Тема | Re: WIP: SCRAM authentication |
Дата | |
Msg-id | CA+TgmoacqxJSojswVDXE_rC_44woWiAXNizEzHTjqF_x_zJs_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: SCRAM authentication (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: WIP: SCRAM authentication
|
Список | pgsql-hackers |
On Tue, Aug 18, 2015 at 10:06 AM, Stephen Frost <sfrost@snowman.net> wrote: > That was the imputus for my earlier suggestion that in a release or two, > we actively make pg_upgrade error (or perhaps warn first, then error, > across two releases) if any of the old verifiers exist. I think there's basically no chance of that being acceptable. The time at which it's possible to get rid of MD5 is going to vary widely between installations. People who are using only libpq or libpq-derived connectors will be able to get rid of it almost immediately, if they want, though some won't. People who are using obscure connectors that are poorly maintained may not even have a version that supports SCRAM for 5 years. Think about how long it took us to roll out the standard_conforming_strings changes, and there were still people who got bitten. > The other concern with a single password verifier is that we're locking > ourselves into a one-verifier-per-role solution when most of the serious > solutions in use today (Active Directory, Kerberos, certificate based > systems) allow for more than one. So what? If you want to delegate authentication to AD or Kerberos, we already support that. That's not a reason to invent the same functionality inside the server. If you've got a tangible plan, other than SCRAM, that would require us to support multiple verifiers, then please say what it is. If not, the mere fact that some other people support it is not a reason why we should. In fact, we generally have taken the approach that needs which are already handled adequately by other tools to do not need to also be handled inside the database. That's not a perfect approach and we always argue about it around the edges, but generally, I think it's served us pretty well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: