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

From Magnus Hagander
Subject Re: [HACKERS] SCRAM authentication, take three
Date
Msg-id CABUevExCeVM9RXjuPksUW8ZS-EpLdEjcqOaNftOOEHB_ekb9Aw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SCRAM authentication, take three  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On Tue, Mar 7, 2017 at 4:36 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
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!

+1!


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.

+1, and let's make sure we get it into 10. We don't want to be stuck with something without flexibility -- then we're going to have to do the whole "is it time yet" dance again. It would be especially bad since the underlying protocol is pluggable.

This seems like an obvious place, but are there any other places where we should also consider something like that for compatibility?

--

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Next
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)