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>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-09T06:43:24Z
Lists: pgsql-hackers 
On 2020-07-07 22:52, Daniel Gustafsson wrote:
> Actually running the tests with the legacy provider loaded yields a fair number
> of errors like these, and somewhere around there I ran out of time for now as
> the CF started.
> 
> -          decrypt
> -----------------------------
> - Lets try a longer message.
> +                         decrypt
> +----------------------------------------------------------
> + Lets try a longer messag\177\177\177\177\177\177\177\177
> 
> Memorizing the "cannot load cipher" errors in an alternative output and
> documenting how to use old ciphers in pgcrypto together with OpenSSL 3.0.0+
> might be the least bad option?  Anyone else have any good ideas on how to get
> this into the testrunner?

I think an alternative test output file would be a legitimate solution 
in the short and mid term.

However, as you mention, and looking at the test output, this might also 
require a bit of work making the handling of these new various error 
conditions more robust.

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