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: Michael Stahl via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 18 Feb 2022 15:03:56 +0100
hello Daniel,
On 28.01.22 08:56, Daniel Stenberg via curl-library wrote:
> Is it time to drop support for NSS?
>
> I don't think any distribution is shipping curl build with NSS by
> default anymore. I know there still are users of it, like the issue that
> triggered me into this shows, but I think most users can be transitioned
> over to other TLS backends.
>
> Maybe we should set a date, maybe late 2022 and if things are still as
> grim-looking in NSS-land as today we then say goodbye?
this mail has been pointed out to me today.
we are shipping curl with NSS in LibreOffice on GNU/Linux and Android
platforms, both in The Document Foundation upstream builds, and also in
downstream builds from a couple commercial vendors.
we are also shipping OpenSSL, mainly because there are other bundled
libraries that cannot use NSS, such as CPython's ssl module and
Postgres's and MariaDB's client connector.
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.
OpenSSL on the other hand must be statically linked into every library
that uses it because inevitably some system library will load the
system's OpenSSL into the process which is a different version and then
symbols from 2 shared libs will trample over each other in ELF global
namespace and crash is inevitable.
hence we are already shipping 3 copies of OpenSSL, which will in some
time increase to 4 copies - as already mentioned in the thread OpenLDAP
has removed support for NSS recently, and thus in case we need to
upgrade OpenLDAP for some CVE in the future we will need to statically
link it to OpenSSL.
(yes, of course we also ship OpenLDAP client libraries. no, it wasn't
my idea.)
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, as there is no way to store certificates in the
LibreOffice profile.
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.
now of course a lot of these problems could be solved if we could just
rely on the system providing sensible shared libraries, but given the
nature of the GNU/Linux ecosystem it's not possible currently and
Flatpak has regrettably not solved that problem yet (currently none of
our customers want Flatpaks, they want rpm/deb builds).
in summary, as a GNU/Linux ISV i like NSS and am sad to see it go.
regards,
michael
PS: on Microsoft/Apple platforms we ship curl built with the system's
TLS libraries.
Date: Fri, 18 Feb 2022 15:03:56 +0100
hello Daniel,
On 28.01.22 08:56, Daniel Stenberg via curl-library wrote:
> Is it time to drop support for NSS?
>
> I don't think any distribution is shipping curl build with NSS by
> default anymore. I know there still are users of it, like the issue that
> triggered me into this shows, but I think most users can be transitioned
> over to other TLS backends.
>
> Maybe we should set a date, maybe late 2022 and if things are still as
> grim-looking in NSS-land as today we then say goodbye?
this mail has been pointed out to me today.
we are shipping curl with NSS in LibreOffice on GNU/Linux and Android
platforms, both in The Document Foundation upstream builds, and also in
downstream builds from a couple commercial vendors.
we are also shipping OpenSSL, mainly because there are other bundled
libraries that cannot use NSS, such as CPython's ssl module and
Postgres's and MariaDB's client connector.
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.
OpenSSL on the other hand must be statically linked into every library
that uses it because inevitably some system library will load the
system's OpenSSL into the process which is a different version and then
symbols from 2 shared libs will trample over each other in ELF global
namespace and crash is inevitable.
hence we are already shipping 3 copies of OpenSSL, which will in some
time increase to 4 copies - as already mentioned in the thread OpenLDAP
has removed support for NSS recently, and thus in case we need to
upgrade OpenLDAP for some CVE in the future we will need to statically
link it to OpenSSL.
(yes, of course we also ship OpenLDAP client libraries. no, it wasn't
my idea.)
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, as there is no way to store certificates in the
LibreOffice profile.
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.
now of course a lot of these problems could be solved if we could just
rely on the system providing sensible shared libraries, but given the
nature of the GNU/Linux ecosystem it's not possible currently and
Flatpak has regrettably not solved that problem yet (currently none of
our customers want Flatpaks, they want rpm/deb builds).
in summary, as a GNU/Linux ISV i like NSS and am sad to see it go.
regards,
michael
PS: on Microsoft/Apple platforms we ship curl built with the system's
TLS libraries.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-18