Hi Daniel,

On Fri, 17 Nov 2017, Daniel Stenberg wrote:

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

Not using it in Git, either.

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

One stupid workaround would of course be to replace the `(size_t)-1` in
`Curl_ssl_multi` by something stupidly large, such as 4096 (with the idea
that no TLS backend-specific data requires that much space, and 4096 being
naturally aligned to even 8-byte boundaries).

That stupid workaround would allow us to not rush the decision on
CURL_GLOBAL_SSL...

Ciao,
Dscho
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-11-17