On 04/12/2017 11:34 AM, Jacob Champion wrote:
It's probably worth noting at this point that, even if &errno is unsafe:
- Windows and BeOS users are still handled explicitly by default in 1.0.x.
- If OpenSSL still provides the deprecated CRYPTO_set_id_callback(), we
can use it instead. We're not making use of the pointer-based THREADID
implementation like we should be, heh, so we're not really getting a
benefit out of the new system.
- This whole problem goes away in 1.1.x.
Latest trunk now takes care of all of these cases -- if you're not on a
platform that has a known safe default implementation, we'll use
CRYPTO_set_id_callback() instead, falling back to the THREADID stuff
only as a last resort.
If anyone would like to help test out the new logic and collect some
data, please also let me know which of the three implementations
(builtin, deprecated, or dangerous) your machine ends up using. mod_ssl
will log a notice on startup that tells you. (My plan is to reduce that
log level to something like debug, once PR60999 is fixed.)
If you're really interested in putting it through its paces, here are
the configuration cachevars that control which implementation is in use.
Note that Windows and BeOS-based machines will *always* use the builtin
implementation, if you're using OpenSSL 1.0.x.
- ac_cv_openssl_use_errno_threadid=yes|no
Indicates whether your machine has a threadsafe errno address. Set
it to 'no' to force a fallback to the deprecated implementation.
- ac_cv_func_CRYPTO_set_id_callback=yes|no
Indicates whether your OpenSSL provides the deprecated callback
implementation. Set both variables to 'no' to force a fallback to
the dangerous (crashy) implementation.
Thanks,
--Jacob
