From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SCRAM authentication, take three |
Date: | 2017-03-07 13:21:39 |
Message-ID: | CAB7nPqQr4nfeS6ChPG4Oe47BkyD2J1QG5rnJMOEn5NZ52hcSfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 7, 2017 at 9:36 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I've now committed the bulk of these patches. Many thanks to everyone
> involved, and especially you, Michael, for your persistence!
Thanks!
> 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.
This is mandatory for Postgres 10. Among all the other subjects this
is high on the list.
> 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.
Without that, we are left with only password_encryption as an option
to create a verifier. I am not sure if people would be fine with this
limitation in PG 10. I'll start a thread tomorrow so let's see.
> 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.
Yep.
> 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.
Fine for me.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Rafia Sabih | 2017-03-07 14:07:47 | Re: Enabling parallelism for queries coming from SQL or other PL functions |
Previous Message | Stephen Frost | 2017-03-07 13:15:41 | Re: One-shot expanded output in psql using \gx |