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: Cristian Rodríguez via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 20 Feb 2022 10:18:19 -0300
On Fri, Feb 18, 2022 at 12:29 PM Michael Stahl via curl-library
<curl-library_at_lists.haxx.se> wrote:
> NSS is much preferred over OpenSSL because it has an ABI;
I do not know which openssl version are you basing your analysis on..
but much work and breakage
have gone in during and after 1.1.x development cycle to make a stable
ABI at least possible.
haven't checked but it is likely that effort continued on 3.x.
> 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.
Well.. yeah. that is one of the many downsides of the approach you are taking..
> 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.
You can add a trusted CA before the handshake takes place..so no. it
is ot the case.
Date: Sun, 20 Feb 2022 10:18:19 -0300
On Fri, Feb 18, 2022 at 12:29 PM Michael Stahl via curl-library
<curl-library_at_lists.haxx.se> wrote:
> NSS is much preferred over OpenSSL because it has an ABI;
I do not know which openssl version are you basing your analysis on..
but much work and breakage
have gone in during and after 1.1.x development cycle to make a stable
ABI at least possible.
haven't checked but it is likely that effort continued on 3.x.
> 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.
Well.. yeah. that is one of the many downsides of the approach you are taking..
> 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.
You can add a trusted CA before the handshake takes place..so no. it
is ot the case.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-20