Don’t call CRYTPO_cleanup_all_ex_data()!

Under normal circumstances, the call is not necessary unless you are debugging 
your code trying to find memory leaks, and want to get rid of all reachable 
OpenSSL memory. ex_data is used by applications to extend OpenSSL, and my guess 
is that it’s used only by a minority. Unless ex_data is used, no memory is 
allocated, so for a majority of users, the call has no effect, and is not 
required. Developers can add their own call to CRYPTO_cleanup_all_ex_data() at 
program termination to make sure they don’t leak memory.

P.S. OpenSSL’s init/cleanup is better in 1.1.0…

-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Sep 16, 2016, at 9:35 AM, Alex Bligh 
<<>> wrote:

On 16 Sep 2016, at 13:44, Short, Todd 
<<>> wrote:

The scenario I’m thinking of is:

1. initialize OpenSSL
2. use OpenSSL ex_data
3. curl_global_init();
4. use curl
5. curl_global_cleanup(); /* which calls CRYPTO_cleanup_all_ex_data() */
6. continue to use OpenSSL ex_data — error/crash

Unfortunately openssl is almost impossible to use correctly in libraries due
to its use of global variables.

Consider for a minute that there are two libraries, libfoo and libbar
that both use OpenSSL. The application does not itself use OpenSSL.
Both have cleanup routines. libfoo does not call libbar or
vice versa. Which one of these would you suggest calls
CRYPTO_cleanup_all_ex_data() ?  Whichever you answer, that
library might be deinitialised first, and the other
library used subsequently in a manner that uses OpenSSL.
I vaguely recall being in that position and it it was the other
library's *deinit* which used OpenSSL (to deinit it), which
caused the issue.

Apart from having a 'stop talking to OpenSSL at all' call, I don't
see a way around this.

Alex Bligh

List admin:

List admin:

Reply via email to