OpenSSL 3.0.0 compatibility

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: OpenSSL 3.0.0 compatibility
Date: 2020-05-28 22:16:47
Message-ID: FEF81714-D479-4512-839B-C769D2605F8A@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Since OpenSSL is now releasing 3.0.0-alpha versions, I took a look at using it
with postgres to see what awaits us. As it is now shipping in releases (with
GA planned for Q4), users will probably soon start to test against it so I
wanted to be prepared.

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.

SSL_CTX_load_verify_locations and X509_STORE_load_locations are deprecated and
replaced by individual calls to load files and directories. These are quite
straightforward, and are implemented like how we handle the TLS protocol API.
DH_check has been discouraged to use for quite some time, and is now marked
deprecated without a 1:1 replacement. The OpenSSL docs recommends using the
EVP API, which is also done in 0001. For now I just stuck it in with version
gated ifdefs, something cleaner than that can clearly be done. 0001 is clearly
not proposed for review/commit yet, it's included in case someone else is
interested as well.

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.

On top of DES keys there are also a lot of deprecations or low-level functions
which breaks pgcrypto in quite a few ways. I haven't tackled these yet, but it
looks like we have to do the EVP rewrite there.

cheers ./daniel

Attachment Content-Type Size
0002-OpenSSL-3.0.0-compatibility-in-tests.patch application/octet-stream 4.8 KB
0001-Compatibility-with-OpenSSL-3.0.0.patch application/octet-stream 7.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-05-28 22:28:13 Re: Fix compilation failure against LLVM 11
Previous Message Markus Winand 2020-05-28 22:08:49 Re: Conflict of implicit collations doesn't propagate out of subqueries