On Wed, May 3, 2017 at 5:26 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: > Ok, gotcha. I disagree, I think we should provide a default. Libpq is in a > better position to make a good choice than most applications. > > I've committed the new PQencryptPasswordConn function, with the default > behavior of doing "show password_encryption", and the changes to use it in > psql and createuser. This closes the open issue with \password.
Well, there is always the counter argument that applications can check for password_encryption by themselves and complete PQencryptPasswordConn and that would be a couple of extra lines in any applications. But honestly, people will appreciate a way to rely on what the backend uses automatically. > On 04/27/2017 07:03 AM, Michael Paquier wrote: >> I think that it is a mistake to move SASLprep out of >> scram_build_verifier, because pre-processing the password is not >> necessary, it is normally mandatory. The BE/FE versions that you are >> adding also duplicate the calls to pg_saslprep(). > > I played with that a little bit, but decided to keep pg_saslprep() out of > scram_build_verifier() after all. It would seem asymmetric to have > scram_build_verifier() call pg_saslprep(), but require callers of > scram_SaltedPassword() to call it. So for consistency, I think > scram_SaltedPassword() should also call pg_saslprep(). That would > complicated the scram_SaltedPassword() function, however. It would need to > report an OOM error somehow, for starters. Not an insurmountable issue, of > course, but it felt cleaner this way, after all, despite the duplication. Okay, I won't fight on that further. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
