Re: scram and \password - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: scram and \password
Date
Msg-id f56a2116-a466-ad6c-03d5-413294bfca9f@iki.fi
Whole thread Raw
In response to Re: scram and \password  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: scram and \password  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 04/05/2017 06:53 PM, Robert Haas wrote:
> On Sat, Mar 25, 2017 at 1:10 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Fri, Mar 24, 2017 at 10:12 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> On 03/24/2017 03:02 PM, Michael Paquier wrote:
>>>>
>>>> In order to close this thread, I propose to reuse the patches I sent
>>>> here to make scram_build_verifier() available to frontends:
>>>>
>>>> https://www.postgresql.org/message-id/CAB7nPqT4yc3u8wspYkWbG088Ndp6asMH3=Zb___Ck89CTvziYQ@mail.gmail.com
>>>>
>>>> And on top of it modify \password so as it generates a md5 verifier
>>>> for pre-9.6 servers and a scram one for post-10 servers by looking at
>>>> the backend version of the current connection. What do you think?
>>>
>>> Yep, sounds like a plan.
>>
>> And attached is a set of rebased patches, with createuser and psql's
>> \password extended to do that.
>
> Heikki, are you going to do something about these?  We're running out of time.

Sorry I've been procrastinating. I'm on it now. (We need to do something 
about this, feature freeze or not..)

At a quick glance, moving pg_frontend_random() to src/common looks like 
a non-starter. It uses pglock_thread() which is internal to libpq, so it 
won't compile as it is. I think I'm going to change 
scram_build_verifier() to take a pre-generated salt as argument, to 
avoid the need for a random number generator in src/common.

- Heikki




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: partitioned tables and contrib/sepgsql
Next
From: Tom Lane
Date:
Subject: Re: partitioned tables and contrib/sepgsql