Re: [HACKERS] scram and \password - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] scram and \password
Date
Msg-id CABUevEwU-6tCtZVcBhrQgjyOn8sKD3T4OGcuzmMtxGM1qT3FrA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly