Re: PostgreSQL12 and older versions of OpenSSL

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL12 and older versions of OpenSSL
Date: 2019-09-28 20:52:18
Message-ID: b2f510bc-5f2c-f1ea-630f-f4d46ba1df3c@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 done
>>> when ssl_protocol_version_to_openssl()'s result is -1. Wouldn't it be
>>> better to report that properly to the user?
>>
>> Our SSL_CTX_set_max_proto_version() is a reimplementation of a function
>> that exists in newer versions of OpenSSL, so it has a specific error
>> behavior. Our implementation should probably not diverge from it too much.
>
> I agree with this point. Now my argument is about logging LOG or
> FATAL within be_tls_init() after the two OpenSSL functions (or our
> wrappers) SSL_CTX_set_min/max_proto_version are called.

committed with that

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-09-28 21:07:59 Re: Standby accepts recovery_target_timeline setting?
Previous Message Tom Lane 2019-09-28 20:37:43 Re: Possible bug: SQL function parameter in window frame definition