libreswan
curl is dropping nss backend
https://curl.se/dev/deprecate.html#nss suggests that next month curl will deprecate the NSS backend. (see also https://bugs.debian.org/1038912).
AFAICT, libreswan currently uses curl only for fetching CRLs over HTTPS in the pluto daemon, entirely in programs/pluto/fetch.c.
Since libreswan depends on libnss, of course it is reasonable to depend on the NSS variant of curl. But as of next month that won't be a supported configuration.
If we build pluto against the OpenSSL or GnuTLS variant of curl, then pluto will depend on two different cryptography libraries (NSS directly, and whatever libcurl transitively depends on). That's unsightly and a bit bloaty, but probably still functional.
Alternately, maybe there's some other HTTP client library that libreswan wants to move to that can support NSS as a crypto backend?
If we build pluto against the OpenSSL or GnuTLS variant of curl, then pluto will depend on two different cryptography libraries (NSS directly, and whatever libcurl transitively depends on). That's unsightly and a bit bloaty, but probably still functional.
On Fedora, at least, this is already happening.
[cagney@bernard nss ]$ ldd /usr/lib64/libcurl.so.4 | grep crypto
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007ff22c200000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007ff22bd83000)
[cagney@bernard nss ]$ rpm -qf /lib64/libcrypto.so.3
openssl-libs-3.0.9-1.fc38.x86_64
just because it links to libcrypto doesn't mean that's the primary backend. :/ on debian libcurl3-nss links to libcrypto as well -- indeed, like libcurl4 (Debian's OpenSSL variant) it links to a strict superset of the shared objects used by libcurl3-gnutls. I think this is due to other libraries used by pluto which in turn link to libcrypto, e.g. libunbound or libldns.
Furthermore, i note that Curl's documentation suggests that NSS's CRL check is "automatic" compared to OpenSSL's CRL check (which is described as "manual"). I don't think that's relevant for libreswan's use (i think libreswan is doing "manual" CRL checks no matter what, since there is no TLS session involved that might automate the CRL check), but i'd appreciate another pair of eyeballs to confirm that.
just an update
in 5.3 while the libreswan package/system/... will still depend on curl, it's only the program _import_crl that will link against it