On Fri, 17 Nov 2017, Daniel Stenberg wrote:

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

Update:

Me and Ray have discussed this topic back and forth extensively on github in
several PRs. We still disagree on the best approach to proceed from here, but
as we have a release coming in less than 48 hours I had to make a decision so
that we at least fix the current bugs at hand.

This morning I landed PR #2107 as commit d661b0afb. It makes libcurl ignore
CURL_GLOBAL_SSL. It becomes a no-op. libcurl will now always initialize the
TLS library stuff and all the relevant TLS internals if built with TLS
support.

The risk: that there's actually a legitimate user somewhere out there who
disables the libcurl SSL init for a good reason and that now will suffer from
some obscure problems. I do however think that if there is such a user, they
should get problems early and immediately. I estimate the risk for this to be
very small.

The backup approach: should the risk turn out real and my estimate be crap (it
has happened before! :-O), the plan is to then backpedal and go with #2112 [*]
instead.

[*] = https://github.com/curl/curl/pull/2112

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