On Sun, 17 Jul 2022, lwthiker via curl-library wrote:
I've just found out about the upcoming deprecation of the NSS support while trying to build curl with it. I'd like to point out a current use case for using curl+NSS as part of "curl-impersonate", a curl fork that I maintain and is available at https://github.com/lwthiker/curl-impersonate. NSS is used there to configure curl to look like Firefox when it comes to the TLS handshake. The project seems to have quite a substantial number of users using it currently, and specifically the Firefox mode.
Thanks for pointing this out, it should certainly be taken into account and used when making a decision about NSS's future in curl.
In the 2022 user survey 3.4% of the users claim they use curl with NSS, so even as I think no distro ships curl with NSS anymore it seems to still at least be in use in niche areas.
I'm still concerned about the fact that 1. NSS is hard to use and 2. that without the Red Hat additions, it is not a very good backend.
The lack of (proper) docs is a risk for insecure code since we might unknowingly use it wrongly/insecurely and it's a pain to work with (bugfix, extend, etc) and it shows that the stewards of the lib don't care much about external users such as curl. Bad signs. (See for example the recent flaw CVE-2022-27781 we had in NSS related code.)
The additional magic that allowed NSS code to read PEM certs from file made curl+NSS get features used by a lot of users requires extra external magic, so when you use curl+NSS outside of Red Hat Linux that's not available and it becomes a less pleasent experience.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
