Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: OpenSSL 3.0.0 compatibility
Date
Msg-id ae8f21fc-95cb-c98a-f241-1936133f466f@2ndQuadrant.com
Whole thread Raw
In response to Re: OpenSSL 3.0.0 compatibility  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: OpenSSL 3.0.0 compatibility
List pgsql-hackers
On 6/1/20 4:33 AM, Peter Eisentraut wrote:
> On 2020-05-30 14:34, Andrew Dunstan wrote:
>>
>> On 5/28/20 6:16 PM, Daniel Gustafsson wrote:
>>>
>>> OpenSSL also deprecates DES keys in 3.0.0, which cause our password
>>> callback
>>> tests to fail with the cryptic error "fetch failed", as the test
>>> suite keys are
>>> encrypted with DES.  0002 fixes this by changing to AES256 (randomly
>>> chosen
>>> among the ciphers supported in 1.0.1+ and likely to be around), and
>>> could be
>>> applied already today as there is nothing 3.0.0 specific about it.
>>>
>>
>> +1 for applying this forthwith. The key in my recent commit 896fcdb230
>> is encrypted with AES256.
>
> I don't see anything in that commit about how to regenerate those
> files, such as a makefile rule.  Is that missing?



You missed these comments in the test file:


# self-signed cert was generated like this:
# system('openssl req -new -x509 -days 10000 -nodes -out server.crt
-keyout server.ckey -subj "/CN=localhost"');
# add the cleartext passphrase to the key, remove the unprotected key
# system("openssl rsa -aes256 -in server.ckey -out server.key -passout
pass:$clearpass");
# unlink "server.ckey";


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?


cheers


andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: pg_dump dumps row level policies on extension tables
Next
From: Daniel Gustafsson
Date:
Subject: Re: OpenSSL 3.0.0 compatibility