On Sat, Dec 9, 2017 at 12:23 AM, Peter Eisentraut
wrote:
> On 12/1/17 18:11, Michael Paquier wrote:
>> 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
On 12/1/17 18:11, Michael Paquier wrote:
> 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
On Fri, Dec 1, 2017 at 11:55 PM, Peter Eisentraut
wrote:
> On 11/30/17 00:36, Michael Paquier wrote:
>> On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
>> 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 als
On 11/30/17 00:36, Michael Paquier wrote:
> On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
> 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_c
On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
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_messa
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 wh
On Thu, Nov 23, 2017 at 4:08 AM, Peter Eisentraut
wrote:
> On 11/19/17 23:08, Michael Paquier wrote:
>> When using "n" or "y", the data sent by the client to the server about
>> the use of channel binding is a base64-encoded string of respectively
>> "n,," (biws) and "y,," (eSws). However, as noti
On 11/19/17 23:08, Michael Paquier wrote:
> When using "n" or "y", the data sent by the client to the server about
> the use of channel binding is a base64-encoded string of respectively
> "n,," (biws) and "y,," (eSws). However, as noticed by Peter E here, a
> v10 server is able to allow connection
(Adding Heikki here because that concerns him as well)
On Mon, Nov 20, 2017 at 2:04 PM, Tom Lane wrote:
> Michael Paquier writes:
>> The attached patch,
>> for REL_10_STABLE, allows a server to accept as well as input "eSws",
>> which is a combination that can now happen. This way, a v10 server
Michael Paquier writes:
> When trying to connect to a v11 client based on current HEAD to a v10
> server using SSL, then the connection would fail.
That's bad ...
> The attached patch,
> for REL_10_STABLE, allows a server to accept as well as input "eSws",
> which is a combination that can now h
HI all,
When a client connects during a SCRAM exchange, it has multiple ways
to let the server know what the client supports or not when using
channel binding:
- "n" -> client doesn't support channel binding.
- "y" -> client does support channel binding but thinks the server does not.
- "p" -> cli
11 matches
Mail list logo
