Re: OpenSSL 3.0.0 compatibility

On Fri, May 29, 2020 at 12:16:47AM +0200, Daniel Gustafsson wrote:
> 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.

Leaving the problems with pgcrypto aside for now, we have also two
parts involving DH_check() deprecation and the load-file APIs for the
backend.

From what I can see, the new APIs to load files are new as of 3.0.0,
but these are not marked as deprecated yet, so I am not sure that it
is worth having now one extra API compatibility layer just for that
now as proposed in cert_openssl.c. Most of the the EVP counterparts,
though, are much older than 1.0.1, except for EVP_PKEY_param_check()
introduced in 1.1.1 :(

By the way, in the previous patch, EVP_PKEY_CTX_new_from_pkey() was
getting used but it is new as of 3.0. We could just use
EVP_PKEY_CTX_new() which does the same work (see
crypto/evp/pmeth_lib.c as we have no library context of engine to pass
down), and is much older, but it does not reduce the diffs. Then the
actual problem is EVP_PKEY_param_check(), new as of 1.1.1, which looks
to be the expected replacement for DH_check().

It seems to me that it would not be a bad thing to switch to the EVP
APIs on HEAD to be prepared for the future, but I would switch to
EVP_PKEY_CTX_new() instead of EVP_PKEY_CTX_new_from_pkey() and add a
configure check to see if EVP_PKEY_param_check() is defined or not.
OPENSSL_VERSION_NUMBER cannot be used because of LibreSSL overriding
it, and I guess that OPENSSL_VERSION_MAJOR, as used in the original
patch, would not work with LibreSSL either.

Any thoughts?
--
Michael