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
signature.asc
Description: PGP signature
