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: Has the time come to drop 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: Mon, 21 Feb 2022 09:56:08 +0100 (CET)
On Fri, 18 Feb 2022, Michael Stahl via curl-library wrote:
> NSS is much preferred over OpenSSL because it has an ABI; you can ship it as
> shared libraries and it's going to work - we are currently shipping NSS but
> it should also work to use it from the system, i attempted to do that some
> time ago but on the RHEL7 baseline it caused some unit test failures so i
> had to abandon that for now.
Sorry, but to me that sounds primarily an argument against (some versions of)
OpenSSL, not a very strong argument in favor of NSS. I would personally rather
push for using another feature-rich alternative, like GnuTLS or wolfSSL.
Libraries that have better future prospects than NSS.
> another advantage of NSS is that we can easily tell it to use the CA and
> user certificates from the user's Mozilla Thunderbird or Firefox profile,
> which is used by LibreOffice's document signature features on GNU/Linux and
> macOS
That's cool, but *could* of course also just be done by (new) code that could
extract that data and provide it to another TLS library. The Mozilla products
are after all (unfortunately) a diminishing user base.
> i believe that the OpenSSL libraries we ship use a hard-coded list of
> built-in trusted CAs, which the user can't modify in any way, but i haven't
> actually checked if that is still the case.
OpenSSL has an API to which you pass in the CA bundle path(s) to use.
> in summary, as a GNU/Linux ISV i like NSS and am sad to see it go.
Thanks for letting us know, as I was totally not aware of your use case.
Date: Mon, 21 Feb 2022 09:56:08 +0100 (CET)
On Fri, 18 Feb 2022, Michael Stahl via curl-library wrote:
> NSS is much preferred over OpenSSL because it has an ABI; you can ship it as
> shared libraries and it's going to work - we are currently shipping NSS but
> it should also work to use it from the system, i attempted to do that some
> time ago but on the RHEL7 baseline it caused some unit test failures so i
> had to abandon that for now.
Sorry, but to me that sounds primarily an argument against (some versions of)
OpenSSL, not a very strong argument in favor of NSS. I would personally rather
push for using another feature-rich alternative, like GnuTLS or wolfSSL.
Libraries that have better future prospects than NSS.
> another advantage of NSS is that we can easily tell it to use the CA and
> user certificates from the user's Mozilla Thunderbird or Firefox profile,
> which is used by LibreOffice's document signature features on GNU/Linux and
> macOS
That's cool, but *could* of course also just be done by (new) code that could
extract that data and provide it to another TLS library. The Mozilla products
are after all (unfortunately) a diminishing user base.
> i believe that the OpenSSL libraries we ship use a hard-coded list of
> built-in trusted CAs, which the user can't modify in any way, but i haven't
> actually checked if that is still the case.
OpenSSL has an API to which you pass in the CA bundle path(s) to use.
> in summary, as a GNU/Linux ISV i like NSS and am sad to see it go.
Thanks for letting us know, as I was totally not aware of your use case.
-- / 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.haxx.se/mail/etiquette.htmlReceived on 2022-02-21