Hi friends!

A long time ago we added the ability to ask libcurl to *not* initialize the
TLS library (which iirc only was OpenSSL at the time) if you removed the
CURL_GLOBAL_SSL bit from the curl_global_init() call.

The idea was that if you already initialized OpenSSL in your application you
might want to avoid that libcurl does it again. I believe there was once a
problem in OpenSSL with doing multiple initializations. I don't think it ever
made much sense for any other backend, but the option remained and is
documented and everything. The default action is of course that libcurl inits
the TLS stuff.

Nowadays though. Is anything or anyone using this feature (disabling
CURL_GLOBAL_SSL) for a good purpose and if so, can you please elaborate on why
and how? (I don't think "I won't use any TLS protocols" is a good reason.)

This feature requires that the application knows very well what TLS backend
libcurl uses and that it knows how to init it the same way or at least
properly.

When we introduced multissl support in libcurl, the application can ask
libcurl in run-time to pick a TLS backend and that makes this case even
weirder. So an application disabling the CURL_GLOBAL_SSL bit in a multissl
case would also init TLS differently based on the chosen backend libcurl will
end up using. Even more unlikely to happen in the real world.

Evgeny Grin recently discovered that libcurl right now crashes when you switch
off CURL_GLOBAL_SSL on a multissl build, no matter if you actually use TLS or
not. (See his PRs in #2089 and #2083 - two different takes at the same
problem.)

Of course we want to fix this, but when working on this case the general
question on what disabling CURL_GLOBAL_SSL actually means comes up and if it
is actually worth still dealing with.

Thoughts and opinions on this are very welcome!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html