Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: About the upcoming deprecation of NSS
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 19 Jul 2022 11:39:50 +0200 (CEST)
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.
Date: Tue, 19 Jul 2022 11:39:50 +0200 (CEST)
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.htmlReceived on 2022-07-19