| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, 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-04-25 18:29:59 |
| Message-ID: | 25550.1493144999@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 25, 2017 at 11:26 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> A) Have PQencryptPassword() return an md5 hash.
>>
>> B) Have PQencryptPassword() return a SCRAM verifier
>>
>> C) Have PQencryptPassword() return a SCRAM verifier if connected to a v10
>> server, and an md5 hash otherwise. This is tricky, because PQencryptPassword
>> doesn't take a PGconn argument. It could behave like PQescapeString() does,
>> and choose md5/scram depending on the server version of the last connection
>> that was established.
> I vote for A - leave PQencryptPassword() as-is, and deprecate it.
> Tell people to use the new function going forward.
+1. I never much liked that magic behavior of PQescapeString, and don't
think we should replicate it elsewhere, so I definitely don't like (C).
And I don't think we can do (B) because that will break the functionality
altogether when talking to an older server. That leaves (A) plus invent
a new function.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-25 18:36:05 | Re: Separation walsender & normal backends |
| Previous Message | Finnerty, Jim | 2017-04-25 18:19:00 | Re: On How To Shorten the Steep Learning Curve Towards PG Hacking... |