Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: OpenSSL 3.0.0 compatibility
Date
Msg-id fc1c85e2-a74e-338e-f1c6-e52f07559a34@2ndquadrant.com
Whole thread Raw
In response to OpenSSL 3.0.0 compatibility  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: OpenSSL 3.0.0 compatibility
List pgsql-hackers
On 2020-05-29 00:16, Daniel Gustafsson wrote:
> Regarding the deprecations, we can either set preprocessor directives or use
> compiler flags to silence the warning and do nothing (for now), or we could
> update to the new API.  We probably want to different things for master vs
> back-branches, but as an illustration of what the latter could look like I've
> implemented this in 0001.

I think we should set OPENSSL_API_COMPAT=10001, and move that along with 
whatever our oldest supported release is going forward.  That declares 
our intention, it will silence the deprecation warnings, and IIUC, if 
the deprecated stuff actually gets removed, you get a clean compiler 
error that your API level is too low.

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

It appears you can load a "legacy provider" to support these keys.  What 
if someone made a key using 0.9.* with an older PostgreSQL version and 
keeps using the same key?  I'm wondering about the implications in 
practice here.  Obviously moving off legacy crypto is good in general.

There is also the question of what to do with the test suites in the 
back branches.

Maybe we will want some user-exposed option about which providers to 
load, since that also affects whether the FIPS provider gets loaded. 
What's the plan there?

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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: "John Bachir"
Date:
Subject: Re: feature idea: use index when checking for NULLs before SET NOT NULL