Horton

Re: OpenSSL 3.0.0 compatibility

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-23T08:17:00Z
Lists: pgsql-hackers 
On Mon, Sep 21, 2020 at 08:18:42PM +0200, Daniel Gustafsson wrote:
> I'm far from fluent in OpenSSL, but AFAICT it has to do with the new provider
> API.  The default value for padding is unchanged, but it needs to be propaged
> into the provider to be set in the context where the old code picked it up
> automatically.  The relevant OpenSSL commit (83f68df32f0067ee7b0) which changes
> the docs to say the function should be called doesn't contain enough
> information to explain why.

Hmm.  Perhaps we should consider making this part conditional on
3.0.0?  But I don't see an actual reason why we cannot do it
unconditionally either.  This needs careful testing for sure.

> Turns out it was coming from when I tested against OpenSSL git HEAD, so it may
> come in alpha7 (or whatever the next version will be).  Let's disregard this
> for now until dust settles, I've dropped the patch from the series.

Yeah.  I have just tried that on the latest HEAD at e771249 and I
could reproduce what you saw.  It smells to me like a regression
introduced by upstream, as per 9a30f40c and c2150f7.  I'd rather wait
for 3.0.0 to be GA before concluding here.  If it proves to be
reproducible with their golden version as a bug (or even not as a
bug), we will need to have a workaround in any case.
--
Michael

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