On Sat, Sep 28, 2019 at 10:52:18PM +0200, Peter Eisentraut wrote:
> committed with that
Thanks, LGTM.
--
Michael
signature.asc
Description: PGP signature
On 2019-09-27 16:20, Michael Paquier wrote:
> On Fri, Sep 27, 2019 at 03:50:57PM +0200, Peter Eisentraut wrote:
>> On 2019-09-27 03:51, Michael Paquier wrote:
>>> Your patch does not issue a ereport(LOG/FATAL) in the event of a
>>> failure with SSL_CTX_set_max_proto_version(), which is something do
On Fri, Sep 27, 2019 at 03:50:57PM +0200, Peter Eisentraut wrote:
> On 2019-09-27 03:51, Michael Paquier wrote:
>> Your patch does not issue a ereport(LOG/FATAL) in the event of a
>> failure with SSL_CTX_set_max_proto_version(), which is something done
>> when ssl_protocol_version_to_openssl()'s re
On 2019-09-27 03:51, Michael Paquier wrote:
> I have tested compilation of REL_12_STABLE with the top of OpenSSL
> 0.9.8, 1.0.0, 1.0.1, 1.0.2, 1.1.0 and 1.1.1. Our SSL tests also pass
> in all the setups I have tested.
great
> Your patch does not issue a ereport(LOG/FATAL) in the event of a
> fa
On Thu, Sep 26, 2019 at 06:24:22PM +0200, Peter Eisentraut wrote:
> Here is my proposed patch, currently completely untested.
I have tested compilation of REL_12_STABLE with the top of OpenSSL
0.9.8, 1.0.0, 1.0.1, 1.0.2, 1.1.0 and 1.1.1. Our SSL tests also pass
in all the setups I have tested.
Y
On Thu, Sep 26, 2019 at 04:43:33PM +0200, Peter Eisentraut wrote:
> On 2019-09-26 06:53, Michael Paquier wrote:
> > So I agree with the proposal to rely on the presence of
> > TLS_MAX_VERSION, and base our decision-making on that.
>
> But then there is this:
>
> commit 04cd70c6899c6b36517b2b07d7a
Here is my proposed patch, currently completely untested.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 35324dbe908a779c9d84b438cb54328cfd74e403 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 2
On 2019-09-26 06:53, Michael Paquier wrote:
> So I agree with the proposal to rely on the presence of
> TLS_MAX_VERSION, and base our decision-making on that.
But then there is this:
commit 04cd70c6899c6b36517b2b07d7a12b2cceba1bef
Author: Kurt Roeckx
Date: Tue Sep 18 22:17:14 2018
Depreca
On Thu, Sep 26, 2019 at 02:03:12AM -0400, Tom Lane wrote:
> What I'm concerned about at the moment is Peter's comment upthread
> that what we seem to be dealing with here is a broken vendor patch,
> not any officially-released OpenSSL version at all. Is it our job
> to work around that situation,
Michael Paquier writes:
> Now that I think about it, another method would be to rely on the fact
> that a given version of OpenSSL does not support TLS 1.1 and 1.2. So
> we could also just add checks based on OPENSSL_VERSION_NUMBER and be
> done with it.
No, that way madness lies. We *know* tha
On Tue, Sep 24, 2019 at 12:43:17PM -0400, Tom Lane wrote:
> One thing I'm wondering is if it's safe to assume that TLS_MAX_VERSION
> will be defined whenever these other symbols are. Looking in an
> 0.9.8x install tree, that doesn't seem to define any of them; while
> in 1.0.1e I see
Yeah, I coul
On Tue, Sep 24, 2019 at 11:52:48PM +0200, Peter Eisentraut wrote:
> That's not actually what this file looks like in the upstream release.
> It looks like the packagers must have patched in the protocol codes for
> TLS 1.1 and 1.2 themselves. Then they should also add the corresponding
> SSL_OP_NO
On Tue, Sep 24, 2019 at 11:25:30AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> ... I wonder if we should really continue to support
>> OpenSSL 0.9.8.
>
> Fair question, but post-rc1 is no time to be moving that goalpost
> for the v12 branch.
Yeah. I worked in the past with SUSE-based app
On 2019-09-24 09:18, Victor Wagner wrote:
> Problem is that some code in src/backend/libpq/be-secure-openssl.c
> assumes that if preprocessor symbols TLS1_1_VERSION and TLS1_2_VERSION
> are defined in the openssl headers, corresponding versions of TLS are
> supported by the library.
>
> It is not
Victor Wagner writes:
> I'm attaching patch which uses solution mentioned above.
> It seems that chedk for SSL_OP_NO_TLSvX_Y is redundant if
> we are checking for TLS_MAX_VERSION.
One thing I'm wondering is if it's safe to assume that TLS_MAX_VERSION
will be defined whenever these other symbols
Alvaro Herrera writes:
> ... I wonder if we should really continue to support
> OpenSSL 0.9.8.
Fair question, but post-rc1 is no time to be moving that goalpost
for the v12 branch.
> Anyway I suppose it's not impossible that third parties are still
> maintaining their 1.0.0 branch,
Another data
On 2019-Sep-24, Victor Wagner wrote:
> Dear hackers,
>
> PostgreSQL 12 documentation states, that minimum required version of
> OpenSSL is 0.9.8. However, I was unable to сompile current
> PGPRO_12_STABLE with OpenSSL 0.9.8j (from SLES 11sp4).
(Nice branch name.) I wonder if we should really co
On Tue, 24 Sep 2019 18:49:17 +0900
Michael Paquier wrote:
> On Tue, Sep 24, 2019 at 10:18:59AM +0300, Victor Wagner wrote:
> > PostgreSQL 12 documentation states, that minimum required version of
> > OpenSSL is 0.9.8. However, I was unable to сompile current
> > PGPRO_12_STABLE with OpenSSL 0.9.8
On Tue, Sep 24, 2019 at 10:18:59AM +0300, Victor Wagner wrote:
> PostgreSQL 12 documentation states, that minimum required version of
> OpenSSL is 0.9.8. However, I was unable to сompile current
> PGPRO_12_STABLE with OpenSSL 0.9.8j (from SLES 11sp4).
I can reproduce that with REL_12_STABLE and th
Dear hackers,
PostgreSQL 12 documentation states, that minimum required version of
OpenSSL is 0.9.8. However, I was unable to сompile current
PGPRO_12_STABLE with OpenSSL 0.9.8j (from SLES 11sp4).
-fno-strict-aliasing -fwrapv -g -O2 -I../../../src/include -D_GNU_SOURCE
-I/usr/include/libxml2
20 matches
Mail list logo
