On Wed, May 3, 2017 at 5:26 PM, Heikki Linnakangas <hlinnaka@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
