Re: [HACKERS] SCRAM authentication, take three - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [HACKERS] SCRAM authentication, take three
Date
Msg-id b081887e-1712-3aa4-7dbe-e012333d50e4@iki.fi
Whole thread Raw
In response to Re: [HACKERS] SCRAM authentication, take three  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] SCRAM authentication, take three  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] SCRAM authentication, take three  (Magnus Hagander <magnus@hagander.net>)
Re: SCRAM authentication, take three  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 03/02/2017 08:50 AM, Michael Paquier wrote:
> Attached is a new patch set. I have combined SASLprep with the rest
> and fixed some conflicts. At the same time when going through NFKC
> this morning I have noticed that the implementation was doing the
> canonical decomposition and reordered the characters using the
> combining classes, but the string recomposition was still missing.
> This is addressed in this patch set, and well as on my dev tree:
> https://github.com/michaelpq/postgres/tree/scram

I've now committed the bulk of these patches. Many thanks to everyone 
involved, and especially you, Michael, for your persistence!

There are a bunch of loose ends, like the SASLprep thing. But the core 
of this patch has been unchanged for some time now, so it's time to move 
ahead.

I left out the new CREATE/ALTER USER ... PASSWORD (... USING '<method>') 
syntax, after all. I think that's still a good idea, but it turned out 
to be largely orthogonal, and this patch was large enough without it. 
Let's discuss that separately, in another thread.

Currently, the AuthenticationSASL protocol message specifies the 
mechanism that the client must use, but as future-proofing, it'd 
probably be best to redefine that to be a list of mechanisms, and let 
the client choose among those. That's not a show-stopper, but would be 
good to get that right in version 10, so that clients can prepare for 
that, even if we only support one mechanism ATM.

I didn't include the last-minute changes to the way you specify this in 
pg_hba.conf. So it's still just "scram". I agree in general that we 
should think about how to extend that too, but I think the proposed 
syntax was overly verbose for what we actually support right now. Let's 
discuss that as a separate thread, as well.

I didn't commit the TAP authentication tests yet. I just didn't have the 
energy to review it all in one go - I will revisit that in the next few 
days.

- Heikki




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] foreign partition DDL regression tests
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner