AWS-LC (and likely BoringSSL) uses thread specific data to store internal
library state which gets freed via a registered destructor when the thread
terminates. If this thread happens to be the main thread, which runs the
leak-detective evaluation, the detective won't observe the corresponding free
of the related memory and erroneously reports it as a leak.
The two places this happens are:
- `RAND_bytes` for storing internal RNG state.
- `ERR_put_error` for storing the per-thread OpenSSL error queue.
References strongswan/strongswan#1907
Closes strongswan/strongswan#2147
"CRYPTO_get_ex_new_index",
/* OpenSSL libssl */
"SSL_COMP_get_compression_methods",
+ /* AWS-LC */
+ "RAND_bytes",
+ "ERR_put_error",
/* NSPR */
"PR_CallOnce",
/* libapr */