Re: [HACKERS] scram and \password
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] scram and \password |
Дата | |
Msg-id | CABUevEwU-6tCtZVcBhrQgjyOn8sKD3T4OGcuzmMtxGM1qT3FrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] scram and \password (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Apr 25, 2017 at 8:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 25, 2017 at 11:26 AM, Heikki Linnakangas <hlinnaka@iki.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.
+1.
В списке pgsql-hackers по дате отправления: