From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Add libpq parameter 'channel_binding'. |
Date: | 2019-10-01 00:43:42 |
Message-ID: | 20191001004342.GC2781@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Mon, Sep 30, 2019 at 05:41:46PM -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> Looks good to me, though I think you need to update the expected error
>> message in the test you just added.
>
> The test case did pass for me when I tried it on an old-openssl machine
> a few hours ago. I don't think this test has any way to exercise the
> code path where the server has support and the client doesn't (or
> vice versa).
The behaviors of "prefer" which make sense with or without channel
binding support on the client-side is actually what matters here when
the server sends back SCRAM-SHA-256-PLUS over SSL. We could use a
compile flag and enforce it in a buildfarm animal, or have more modes
within the parameter, but the gains are not really worth the
code complications in my opinion, and the parameter is already
complicated enough.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-10-01 01:53:18 | pgsql: Add transparent block-level memory accounting |
Previous Message | Andres Freund | 2019-09-30 23:08:59 | Re: pgsql: Stamp 12.0. |