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.html
