OpenSSL 3 non-deprecated APIs are not implemented

[pemensik]

I started looking inside ldns and have found it masks deprecated API calls for OpenSSL 3 by CFLAGS="-DOPENSSL_API_COMPAT=10100 $CFLAGS" in configure. Quite a lot of functionality still requires deprecated calls. At least creating DSA and RSA keys should be converted into EVP_PKEY_fromdata usage and create directly EVP_PKEY from functions like ldns_key_buf2rsa_raw.

While it should be possible to keep backward compatibility when those APIs are still available, I think possibility to use only non-deprecated APIs should be started on. Eventually it would have to be required to switch. At least optional support would be great for a start.

EVP_PKEY-RSA(7), OSSL_PARAM_int(3ossl) and OSSL_PARAM_BLD manuals might help.

That would be prerequisite for implementing EVP_PKEY_CTX_new_from_name key creation using alternative providers as a replacement for ENGINE support deprecated.

[pemensik]

Once that done, I think ldns_key_buf2rsa and ldns_key_buf2dsa functions should be marked deprecated and have alternative functions, which would provide directly EVP_KEY. Avoiding use of the RSA structure in functions like ldns_verify_rrsig_rsasha256_raw. Together with all other functions accessing non-EVP structures. ldns_key_set_rsa_key, ldns_key_set_dsa_key, ldns_key_new_frm_fp_rsa, ldns_key_new_frm_fp_dsa would be other examples.

[Michael-Panic]

Hello,

We're looking to use ldns in our products and encountered the same issue. A while back we rewrote all the OpenSSL 1 calls in our code to OpenSSL 3 and contributed some of that work back to libssh2. We would like to do the same with ldns if possible.

As we did with libssh2, we would keep support for older versions of OpenSSL and use #if OPENSSL_VERSION_NUMBER >= 0x30000000L to keep the OpenSSL 3 code separate.

If we submitted a pull request for this, would it be welcome?

[wtoorop]

If we submitted a pull request for this, would it be welcome?

Absolutely!