Re: [HACKERS] scram and \password
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] scram and \password |
Дата | |
Msg-id | CAB7nPqRb5D4L4A1CAF+n82xQR1cy5EisW5cnPWOyLyEgke=sAg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] scram and \password (Joe Conway <mail@joeconway.com>) |
Список | pgsql-hackers |
On Tue, Mar 14, 2017 at 9:54 AM, Joe Conway <mail@joeconway.com> wrote: > On 03/12/2017 08:10 PM, Michael Paquier wrote: >> OK, so what about doing the following then: >> 1) Create pg_role_password_type(oid), taking a role OID in input and >> returning the type. > > That version would make sense for administrative use. I still think we > might want a version of this that takes no argument, works on the > current_user, and is executable by anyone. Sure. >> 2) Extend PQencryptPassword with a method, and document. Plaintext is forbidden. > > Check, although if "plain" were allowed as a method for the sake of > consistency/completeness the function could just immediately return the > argument. > >> 3) Extend \password in psql with a similar -method=scram|md5 argument, >> and forbid the use of "plain" format. > > Not sure why we would forbid "plain" here unless we remove it entirely > elsewhere. OK. I don't mind about those two, as long as documentation is clear enough about what using plain leads to. >> After thinking about it, extending PQencryptPassword() would lead to >> future breakage, which makes it clear to not fall into the trap of >> having password_encryption set to scram in the server's as well as in >> pg_hba.conf and PQencryptPassword() enforcing things to md5. > > I'm not grokking this statement To grok: "To understand profoundly through intuition or empathy.". Learning a new thing everyday. -- Michael
В списке pgsql-hackers по дате отправления: