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

From Tom Lane
Subject Re: [HACKERS] scram and \password
Date
Msg-id 25550.1493144999@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] scram and \password  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Finnerty, Jim"
Date:
Subject: Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PGHacking...
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Separation walsender & normal backends