curl-library
Re: libcurl documentation bug
Date: Thu, 15 Sep 2016 17:10:11 +0200 (CEST)
On Thu, 15 Sep 2016, Short, Todd wrote:
> The intent of the CRYPTO_cleanup_all_ex_data() is to cleanup memory at the
> termination of the program. As you’ve discovered, documentation for that
> function is, ahem, very poor.
It's not even poor. It doesn't exist. At least they've cleaned it up in
1.1.0...
> CRYPTO_cleanup_all_ex_data() is only to be called when the application is
> completely done using OpenSSL. The FAQ
> (https://www.openssl.org/docs/faq.html#PROG13) indicates that
> CRYPTO_cleanup_all_ex_data() is a “”Brutal” (thread-unsafe)
> Application-global cleanup function”. Code comments for the function
> indicate:
curl_global_cleanup() is also documented to not be thread safe.
> I would recommend changing the curl documentation rather than changing code.
> Curl’s use of OpenSSL is correct as long as curl_global_cleanup() is called
> only once at program termination. The problem is exacerbated when another
> portion of the program uses OpenSSL also.
If another portion of the program is using OpenSSL then you're really in the
deep end as the OpenSSL API really has trouble with that and it's been a long
standing pain point. But if you do, then maybe switch off the CURL_GLOBAL_SSL
from curl_global_init() and init/cleanup OpenSSL yourself?
What's unfortunate with changing the docs is that we've already told users
they can use the function like this since 2006. Suddenly changing this is in
fact a minor ABI breakage. Also, I really hate documentating exceptions to our
API based on what specific TLS library that is used.
> Of course, this is only a problem if ex_data is used within OpenSSL by the
> application.
Yes, and in combination with calling curl_global_cleanup() before the end of
the program's life time.
Decisions, decisions...
-- / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-09-15