On Mon, Sep 30, 2019 at 02:20:29PM -0400, Tom Lane wrote:
> Jeff Davis writes:
>> For 2-3, shouldn't we error at an earlier stage? The user of the client
>> has requested something impossible to satisfy.
>
> Can't get excited about that. It'd require duplicating this code
> somewhere else, which
On Mon, Sep 30, 2019 at 05:41:46PM -0400, Tom Lane wrote:
> Jeff Davis 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 t
Jeff Davis 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 serve
On Mon, 2019-09-30 at 16:08 +0900, Michael Paquier wrote:
> So, something like the attached looks better to me. Using a server
> which publishes SCRAM-SHA-256-PLUS, I get the following over SSL:
> 1) client supports channel binding:
> 1-1) channel_binding = disable => OK, with SCRAM-SHA-256
> 1-2
Jeff Davis writes:
> For 2-3, shouldn't we error at an earlier stage? The user of the client
> has requested something impossible to satisfy.
Can't get excited about that. It'd require duplicating this code
somewhere else, which is a maintenance issue. And the case of building
with obsolete Ope
On Mon, 2019-09-30 at 16:08 +0900, Michael Paquier wrote:
> So, something like the attached looks better to me. Using a server
> which publishes SCRAM-SHA-256-PLUS, I get the following over SSL:
> 1) client supports channel binding:
> 1-1) channel_binding = disable => OK, with SCRAM-SHA-256
> 1-2
Michael Paquier writes:
> So, something like the attached looks better to me.
+1
regards, tom lane
On Mon, Sep 30, 2019 at 03:45:39PM +0900, Michael Paquier wrote:
> If the server publishes SCRAM-SHA-256-PLUS and the server does not
> support channel binding, then we get this error message:
> "channel binding is required, but server did not offer an
> authentication method that supports channel
On Mon, Sep 30, 2019 at 08:47:33AM +0900, Michael Paquier wrote:
> On Sun, Sep 29, 2019 at 12:51:31PM -0400, Tom Lane wrote:
>> Another point is that this error message is misleading --- or at least
>> would be misleading if the server had X509_get_signature_nid and the
>> client didn't.
>>
>> -#if
On Sun, Sep 29, 2019 at 11:39:12PM -0400, Tom Lane wrote:
> Feel free to deal with both.
Thanks. Will do so now then.
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> On Mon, Sep 30, 2019 at 08:47:33AM +0900, Michael Paquier wrote:
>> Yes, it looks sensible to do that.
> Tom, would you prefer taking take of both issues by yourself? Do you
> mind if I handle both things? Or I could just commit my fix first,
> then leave it to you for
On Mon, Sep 30, 2019 at 08:47:33AM +0900, Michael Paquier wrote:
> Yes, it looks sensible to do that.
Tom, would you prefer taking take of both issues by yourself? Do you
mind if I handle both things? Or I could just commit my fix first,
then leave it to you for the second one. I don't mind doi
On Sun, Sep 29, 2019 at 12:51:31PM -0400, Tom Lane wrote:
> I found out the hard way that the added ssl tests fall over on a
> platform that doesn't HAVE_X509_GET_SIGNATURE_NID:
>
> [...]
>
> I don't think that it's acceptable for the test to fail on a platform
> that we're willing to compile on.
Jeff Davis writes:
> Add libpq parameter 'channel_binding'.
I found out the hard way that the added ssl tests fall over on a
platform that doesn't HAVE_X509_GET_SIGNATURE_NID:
# Running: psql -X -A -t -c SELECT $$connected with user=ssltestuser channel_bin
ding=require$$ -d dbname=trustdb sslmod
14 matches
Mail list logo
