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