On Fri, Dec 1, 2017 at 11:55 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 11/30/17 00:36, Michael Paquier wrote:
>> On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
>> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>>> On 11/22/17 21:08, Michael Paquier wrote:
>>>> Yes, agreed. This patch looks good to me. In fe-auth-scram.c, it would
>>>> be also nice to add a comment to keep in sync the logics in
>>>> build_client_first_message() and build_client_final_message() which
>>>> assign the cbind flag value.
>>>
>>> Could you clarify what comment you would like to have added or changed?
>>
>> Sure. Here is with the attached patch what I have in mind. The way
>> cbind-flag is assigned in the client-first message should be kept
>> in-sync with the way the client-final message builds the binding data
>> in c=. It could be possible to add more sanity-checks based on
>> assertions by keeping track of the cbind-flag assigned in the
>> client-first message as your upthread patch is doing in the backend
>> code, but I see a simple comment as a sufficient reminder.
>
> Committed with that comment, thanks.
Cool. Thanks. For REL_10_STABLE, I would suggest the attached patch
then. This ensures that eSws is checked in the final message and that
the cbind-flag sent in the first message maps with the data of the
final message in the backend. I have checked with the following
configurations with a v10 backend:
- v11 libpq with SSL
- v11 libpq without SSL
- v10 libpq with SSL
- v10 libpq without SSL
And in all cases the connection is accepted as it should.
--
Michael