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: Mon, 21 Feb 2022 14:44:51 +0100
On 21.02.22 09:56, Daniel Stenberg wrote:
> 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.
GnuTLS is LGPL, which some people find objectionable for bundling (not
me or my employer); one problem is that it's not possible to ship it in
Apple's App Store.
hmm ... i've never looked at GnuTLS before... its name here is
"libgnutls.so.30" - that's a rather large number? so this thing doesn't
have a stable ABI either?
https://www.gnutls.org/abi-tracker/timeline/gnutls/
RHEL7 has GnuTLS 3.3.29 which is named libgnutls.so.28.
so, neither using system GnuTLS nor bundling GnuTLS looks likely to
solve any problem for us currently.
i've never heard of wolfSSL, and i doubt it's available in RHEL... oh:
> dnf search wolfssl
No matches found.
this library is so obscure it's not even packaged in current Fedora?
doesn't really inspire confidence.
well maybe it's implementation is technically awesome, but as we have
seen with the success of OpenSSL that really doesn't matter.
... of course the main problem is that most if not all of the external
libraries that we bundle that currently use OpenSSL do so because it is
the only option.
>> 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.
possibly, but at least we know that every user of our signature feature
on non-Windows platforms is a Mozilla product user as they have to use
its UI to add their certificate :)
>> 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.
just replied to this point in the other mail.
Date: Mon, 21 Feb 2022 14:44:51 +0100
On 21.02.22 09:56, Daniel Stenberg wrote:
> 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.
GnuTLS is LGPL, which some people find objectionable for bundling (not
me or my employer); one problem is that it's not possible to ship it in
Apple's App Store.
hmm ... i've never looked at GnuTLS before... its name here is
"libgnutls.so.30" - that's a rather large number? so this thing doesn't
have a stable ABI either?
https://www.gnutls.org/abi-tracker/timeline/gnutls/
RHEL7 has GnuTLS 3.3.29 which is named libgnutls.so.28.
so, neither using system GnuTLS nor bundling GnuTLS looks likely to
solve any problem for us currently.
i've never heard of wolfSSL, and i doubt it's available in RHEL... oh:
> dnf search wolfssl
No matches found.
this library is so obscure it's not even packaged in current Fedora?
doesn't really inspire confidence.
well maybe it's implementation is technically awesome, but as we have
seen with the success of OpenSSL that really doesn't matter.
... of course the main problem is that most if not all of the external
libraries that we bundle that currently use OpenSSL do so because it is
the only option.
>> 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.
possibly, but at least we know that every user of our signature feature
on non-Windows platforms is a Mozilla product user as they have to use
its UI to add their certificate :)
>> 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.
just replied to this point in the other mail.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-21