> On 30 Apr 2020, at 01:14, Michael Paquier wrote:
>
> On Wed, Apr 29, 2020 at 01:57:49PM +0200, Daniel Gustafsson wrote:
>> Working in the TLS corners of the backend, I found while re-reviewing and
>> re-testing for the release that this patch actually was a small, but vital,
>> brick shy of a l
On Wed, Apr 29, 2020 at 01:57:49PM +0200, Daniel Gustafsson wrote:
> Working in the TLS corners of the backend, I found while re-reviewing and
> re-testing for the release that this patch actually was a small, but vital,
> brick shy of a load. The error handling is always invoked due to a set of
>
Working in the TLS corners of the backend, I found while re-reviewing and
re-testing for the release that this patch actually was a small, but vital,
brick shy of a load. The error handling is always invoked due to a set of
missing braces. Going into the check will cause the context to be freed a
On Thu, Mar 19, 2020 at 10:54:35PM +0100, Daniel Gustafsson wrote:
> In this message we aren't quoting the TLS protocol setting:
> + (errmsg("%s setting %s not supported by this build",
> ..but in this detail we are:
> + errdetail("\"%s\" cannot be higher than \"%s\"",
> Perhaps
> On 7 Feb 2020, at 01:33, Michael Paquier wrote:
>
> On Thu, Feb 06, 2020 at 11:30:40PM +0100, Daniel Gustafsson wrote:
>> Or change to the v1 patch in this thread, which avoids the problem by doing
>> it
>> in the OpenSSL code. It's a shame to have generic TLS functionality be
>> OpenSSL
>>
On Thu, Feb 06, 2020 at 11:30:40PM +0100, Daniel Gustafsson wrote:
> Or change to the v1 patch in this thread, which avoids the problem by doing it
> in the OpenSSL code. It's a shame to have generic TLS functionality be
> OpenSSL
> specific when everything else TLS has been abstracted, but not w
> On 6 Feb 2020, at 20:04, Tom Lane wrote:
> I think this should be reverted. Perhaps there's a way to do it without
> these problems, but we failed to find one in the past.
Or change to the v1 patch in this thread, which avoids the problem by doing it
in the OpenSSL code. It's a shame to have
Michael Paquier writes:
> On Thu, Jan 16, 2020 at 10:00:52AM +0900, Michael Paquier wrote:
>> Thanks for the review. Let's wait a couple of days to see if others
>> have objections or more comments about this patch, but I'd like to
>> fix the issue and backpatch down to 12 where the parameters ha
On 2020-01-15 03:28, Michael Paquier wrote:
Good points. And the get routines are not that portable in OpenSSL
either even if HEAD supports 1.0.1 and newer versions... Attached is
an updated patch which uses a GUC check for both parameters, and
provides a hint on top of the original error messa
On Thu, Jan 16, 2020 at 10:00:52AM +0900, Michael Paquier wrote:
> Thanks for the review. Let's wait a couple of days to see if others
> have objections or more comments about this patch, but I'd like to
> fix the issue and backpatch down to 12 where the parameters have been
> introduced.
And com
On Wed, Jan 15, 2020 at 06:34:39PM +0100, Daniel Gustafsson wrote:
> This is pretty much exactly the patch I was intending to write for this, so +1
> from me.
Thanks for the review. Let's wait a couple of days to see if others
have objections or more comments about this patch, but I'd like to
fix
> On 15 Jan 2020, at 03:28, Michael Paquier wrote:
>
> On Tue, Jan 14, 2020 at 11:21:53AM +0100, Daniel Gustafsson wrote:
>> On 14 Jan 2020, at 04:54, Michael Paquier wrote:
>>> Please note that OpenSSL 1.1.0 has added two routines to be able to
>>> get the min/max protocols set in a context, ca
On Tue, Jan 14, 2020 at 11:21:53AM +0100, Daniel Gustafsson wrote:
> On 14 Jan 2020, at 04:54, Michael Paquier wrote:
>> Please note that OpenSSL 1.1.0 has added two routines to be able to
>> get the min/max protocols set in a context, called
>> SSL_CTX_get_min/max_proto_version. Thinking about o
> On 14 Jan 2020, at 04:54, Michael Paquier wrote:
>
> Hi all,
> (Daniel G. in CC.)
>
> As discussed on the thread to be able to set the min/max SSL protocols
> with libpq, when mixing incorrect bounds the user experience is not
> that good:
> https://www.postgresql.org/message-id/9cfa34ee-f670
14 matches
Mail list logo
