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
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 |