Horton

Re: OpenSSL 3.0.0 compatibility

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Daniel Gustafsson <daniel@yesql.se>, Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-22T09:37:57Z
Lists: pgsql-hackers 
On 2020-09-18 16:11, Daniel Gustafsson wrote:
> Since we support ciphers that are now deprecated, we have no other choice than
> to load the legacy provider.

Well, we could just have deprecated ciphers fail, unless the user loads 
the legacy provider in the OS configuration.  There might be an argument 
that that is more proper.

As a more extreme analogy, what if OpenSSL remove a cipher from the 
legacy provider?  Are we then obliged to reimplement it manually for the 
purpose of pgcrypto?  Probably not.

The code you wrote to load the necessary providers is small enough that 
I think it's fine, but it's worth pondering this question briefly.

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

Commits

  1. Define OPENSSL_API_COMPAT

  2. Add alternative output for OpenSSL 3 without legacy loaded

  3. Disable OpenSSL EVP digest padding in pgcrypto

  4. pgcrypto: Check for error return of px_cipher_decrypt()

  5. OpenSSL 3.0.0 compatibility in tests

  6. Make ssl certificate for ssl_passphrase_callback test via Makefile

  7. Provide a TLS init hook