Re: scram and \password

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: scram and \password
Date: 2017-05-03 12:35:38
Message-ID: CAB7nPqS-tQ1yZGzimhRD_rL0Re2L7_AumK-F2hhC1jwmwca1Sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2017-05-03 12:44:02 Re: [HACKERS] Re: BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode
Previous Message Haribabu Kommi 2017-05-03 12:33:24 Re: Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode