From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        Michael Paquier <michael.paquier@gmail.com>,
        Noah Misch <noah@leadboat.com>, Jeff Janes <jeff.janes@gmail.com>,
        Joe Conway <mail@joeconway.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: scram and \password
In-reply-to: 
 <CA+Tgmob3oL+xLxMgD6zmhhDab62yr67W4bbALT3G_swkG6NmPg@mail.gmail.com>
References: <a8b0d5cb-35d4-d686-3fae-f743659ae346@iki.fi>
 <CAB7nPqSjSmYK7H3S8A98giR6Jb=jKKTOMMruK1Kxw5Lfxc+Baw@mail.gmail.com>
 <fe2c096e-7b06-3e8e-0804-109def6b5d98@iki.fi>
 <CAB7nPqQ3QiPMgGv5OCz1wsocx7PHdZg5ursQOpyOb96AZuvmGA@mail.gmail.com>
 <5478ab75-404f-9490-9355-dc1365ce3d7f@iki.fi>
 <CAB7nPqTLzbHp5XmREoqiL31uF8VRz4jM1VhDRMZLOJuVg8gZoQ@mail.gmail.com>
 <dead641a-1fc8-0fd7-89d6-b818ac61b31a@iki.fi>
 <CAB7nPqQmJ5t=rd67paE7DWxuSi0C4X=5_pnzZchH7qFkBHy==A@mail.gmail.com>
 <CA+TgmoYk+xfnvYC4xtQD4qFdu7xKn6bRLC-baH5MDdtyCSxg6w@mail.gmail.com>
 <f56a2116-a466-ad6c-03d5-413294bfca9f@iki.fi>
 <20170410035323.GA2846583@tornado.leadboat.com>
 <CAB7nPqSbsCBCxy8-DtwzRxYgTnbGUtY4uFEkLQhG=R=uo=g8Fw@mail.gmail.com>
 <66e776c9-e02c-3683-28df-339f7f64ea66@iki.fi>
 <CAB7nPqSWP9J9PzeC7=-WjuuaL57_d+EawmzJNVsM+m7Y4gRRBA@mail.gmail.com>
 <c32a2be9-f25d-30e8-6d48-64e1801a910f@iki.fi>
 <57f8c243-2362-e7b8-4c56-e752ba6edf6c@iki.fi>
 <CA+Tgmob3oL+xLxMgD6zmhhDab62yr67W4bbALT3G_swkG6NmPg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 26 Apr 2017 12:38:10 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7610.1493225874.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Apr 2017 12:57:54 -0400
Message-ID: <7611.1493225874@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas <hlinnaka@iki.fi> wro=
te:
>> * If algorithm is not given explicitly, PQencryptPasswordConn() queries
>> "SHOW password_encryption", and uses that. That is documented, and it is
>> also documented that it will *not* issue queries, and hence will not blo=
ck,
>> if the algorithm is given explicitly. That's an important property for s=
ome
>> applications. If you want the default behavior without blocking, query "=
SHOW
>> password_encryption" yourself, and pass the result as the 'algorithm'.

> TBH, I'd just require the user to specify the algorithm explicitly.
> Having it run SHOW on the server seems wonky.  It introduces a bunch
> of failure modes for ... no real benefit, I think.

Yeah.  Blocking is the least of your worries --- what about being in
a failed transaction, for instance?

However, it's not entirely true that there's no real benefit.  If the
client app has to specify the algorithm then client code will need
extension every time we add another algorithm.  Maybe that's going to
happen so seldom that it's not a big deal, but it would be nice to
avoid that.

Would it be worth making password_encryption be GUC_REPORT so that
it could be guaranteed available, without a server transaction,
from any valid connection?  I'm generally resistant to adding
GUC_REPORT flags, but maybe this is a time for an exception.

			regards, tom lane


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers