httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: Fixing more OpenSSL callback crashes
Date Wed, 19 Apr 2017 15:54:49 GMT
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.


View raw message