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!

[AlexanderBand]

We're looking to use ldns in our products

To manage expectation properly: of course we are happy to accept a pull request, but I would like clarify that NLnet Labs does not actively develop ldns. We only fix critical bugs and occasionally add functionality, for example for an IETF Hackathon, but nothing more than that.

In fact, we are reimplementing the most commonly used ldns example programs in Rust, based on our domain library. The first iteration of dnst will provide drop in replacements for the following functionality:

• key2ds
• keygen
• nsec3hash
• signzone
• notify
• update

The dnst project will continue to be maintained and expanded going forward, so I would highly recommend relying on this project in due course. If you have a feature request, we are eager to hear from you.

https://github.com/NLnetLabs/dnst

[pemensik]

@AlexanderBand it seems a little too early for that. ldns library is somehow powerful enough for any serious work. If you say it like this, it means we should look for ldns replacement. Rust code is definitely not usable for us at the moment. I have tried to package dnsi, but it has too many dependencies.

I do not think it is possible to replace full functionality of ldns with rust code. Especially I doubt it provides C bindings usable from C code. Is there other C library, which is recommended to be used as ldns replacement? LDNS has also python and perl bindings.

Should we propose using unbound libraries to be used as a replacement? I think they are derived from original ldns anyway.

[pemensik]

We have support for opendnssec in RHEL and Fedora, which depends also on ldns library. I understand that many of those tools were not intended to be production quality. But since they works well, they were used. We use many of them especially in tests written for our integration components. Do not have all examples, but need the library.

But to keep library itself providing functionality, it needs to stop using deprecated calls. They would be eventually removed from OpenSSL.

These are dependencies gathered today on Fedora Rawhide.

dnsperf were rewritten from bind9-libs to ldns. flamethrower depends on it, dnssec-trigger as well. libreswan too. opendnssec as well. I think ldns library has no obvious replacements.

We can talk about replacing ldns tools.

# dnf repoquery --whatrequires ldns
Updating and loading repositories:
Repositories loaded.
dnsperf-0:2.12.0-5.fc41.x86_64
dnssec-trigger-0:0.17-37.fc42.x86_64
flamethrower-0:0.11.0-28.fc41.x86_64
ldns-devel-0:1.8.4-1.fc42.i686
ldns-devel-0:1.8.4-1.fc42.x86_64
ldns-utils-0:1.8.4-1.fc42.x86_64
libreswan-0:5.1-1.fc42.x86_64
netresolve-backends-aresdns-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-backends-aresdns-0:0.0.1-0.39.20160317git.fc40.x86_64
netresolve-backends-avahi-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-backends-avahi-0:0.0.1-0.39.20160317git.fc40.x86_64
netresolve-backends-compat-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-backends-compat-0:0.0.1-0.39.20160317git.fc40.x86_64
netresolve-backends-ubdns-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-backends-ubdns-0:0.0.1-0.39.20160317git.fc40.x86_64
netresolve-compat-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-compat-0:0.0.1-0.39.20160317git.fc40.x86_64
netresolve-core-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-core-0:0.0.1-0.39.20160317git.fc40.x86_64
netresolve-tools-0:0.0.1-0.39.20160317git.fc40.i686
netresolve-tools-0:0.0.1-0.39.20160317git.fc40.x86_64
nordugrid-arc-plugins-needed-0:6.21.0-1.fc42.x86_64
opendnssec-0:2.1.14-0.3rc1.fc42.x86_64
perl-ldns-0:1.8.4-1.fc42.x86_64
python3-ldns-0:1.8.4-1.fc42.x86_64