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. > 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. > 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 Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
