Re: OpenSSL 3.0.0 compatibility

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 compatibility
Date: 2020-06-02 18:45:11
Message-ID: e0087842-0fb6-b152-af80-885b5b27954c@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 6/2/20 4:57 AM, Peter Eisentraut wrote:
> On 2020-06-01 15:23, Andrew Dunstan wrote:
>>
>> On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
>>>> On 1 Jun 2020, at 13:58, Andrew Dunstan
>>>> <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>>>> If you want I can add a rule for it to the Makefile, although who
>>>> knows
>>>> what commands will actually apply when the certificate runs out?
>>> Being able to easily regenerate the testdata, regardless of
>>> expiration status,
>>> has proven very helpful for me when implementing support for new TLS
>>> backends.
>>> +1 for adding it to the Makefile.
>>>
>> OK, here's a patch.
>
> In src/test/ssl/ we have targets sslfiles and sslfiles-clean, and here
> we have ssl-files and ssl-files-clean.  Let's keep that consistent.
>
> Or, why not actually use the generated files from src/test/ssl/
> instead of making another set?

Honestly, I think we've spent plenty of time on this already. I don't
see a problem with each module having its own certificate(s) - that
makes them more self-contained -  nor any great need to have the targets
named the same.

cheers

andrew

--
Andrew Dunstan https://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 Vik Fearing 2020-06-02 19:28:48 Re: Default gucs for EXPLAIN
Previous Message Hamid Akhtar 2020-06-02 18:38:18 Re: Should we remove a fallback promotion? take 2