Re: Fixing more OpenSSL callback crashes

[Ruediger Pluem <rp...@apache.org>]

On 04/19/2017 05:54 PM, Jacob Champion wrote:
> 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.

Just as a heads up as I currently don't have time to investigate further. I get the below on CentOS 6.9 64 bit, which
puzzles me a little bit as I would expect the errno addresses to be different in different threads on my OS.

[Thu May 04 06:17:13.723918 2017] [ssl:notice] [pid 2629:tid 140039001335552] AH10028: using deprecated
CRYPTO_set_id_callback for OpenSSL


OpenSSL used is the one delivered by CentOS: openssl-1.0.1e-57.el6.x86_64

Regards

Rüdiger

Re: Fixing more OpenSSL callback crashes

[Ruediger Pluem <rp...@apache.org>]

On 05/04/2017 05:47 PM, Jacob Champion wrote:
> On 05/03/2017 11:25 PM, Ruediger Pluem wrote:
>> Just as a heads up as I currently don't have time to investigate further. I get the below on CentOS 6.9 64 bit, which
>> puzzles me a little bit as I would expect the errno addresses to be different in different threads on my OS.
>>
>> [Thu May 04 06:17:13.723918 2017] [ssl:notice] [pid 2629:tid 140039001335552] AH10028: using deprecated
>> CRYPTO_set_id_callback for OpenSSL
>>
>> OpenSSL used is the one delivered by CentOS: openssl-1.0.1e-57.el6.x86_64
> 
> Do you use an installed APR or build using --with-included-apr? The configure test that determines whether your errno is
> safe has to be linked against an already-built APR; otherwise the fallbacks come into play.

This is likely the cause for this. I have apr trunk dropped in the srclib directory and build this together with httpd
trunk.
You mentioned this in the threads. I forgot about this :-). Thanks for the reminder.

Regards

Rüdiger

Re: Fixing more OpenSSL callback crashes

[Jacob Champion <ch...@gmail.com>]

On 05/04/2017 09:39 AM, Jacob Champion wrote:
> On 05/04/2017 09:36 AM, William A Rowe Jr wrote:
>> Ugh... This suggests we've further broken crosscompile, just noticed
>> this based on your comment.
>
> Why? Cross-compilation uses the same fallback mechanism.

To expand on this, there are three choices for implementation for older 
(pre-1.1.0) OpenSSLs:

- Builtin (optimal on some platforms, nonexistent or unsafe on others)
- Deprecated (but believed safe enough for most)
- Dangerous (but still apparently good enough for a bunch of people?)

Builtin is only used if we can *prove* that the builtin implementation 
is available and safe. Some environments (Windows + 1.0.x) are known to 
have safe builtins; everyone else has to run a test.

If we can't run that test for any reason, we fall back to the Deprecated 
implementation. If that API is no longer available (e.g. 
OPENSSL_NO_DEPRECATED is in use), we have no choice but to use the 
Dangerous implementation.

So since we can't run a test executable on a cross-compile target, if 
you're cross-compiling to a platform that isn't "known safe", we'll fall 
back to the Deprecated implementation if it's available. That choice can 
be overridden with a cachevar, if you know your platform guarantees 
safety -- ac_cv_openssl_use_errno_threadid in this case.

--Jacob

Re: Fixing more OpenSSL callback crashes

[Jacob Champion <ch...@gmail.com>]

On 05/04/2017 09:36 AM, William A Rowe Jr wrote:
> Ugh... This suggests we've further broken crosscompile, just noticed
> this based on your comment.

Why? Cross-compilation uses the same fallback mechanism. If a user 
doesn't like the conservative choice, he/she should set the cachevars to 
override the defaults, per usual.

(If you find that my system *doesn't* work for cross-compilation, please 
let me know; that's a bug. :D But I did have it in mind when I wrote it.)

--Jacob

Re: Fixing more OpenSSL callback crashes

[William A Rowe Jr <wr...@rowe-clan.net>]

On May 4, 2017 10:47 AM, "Jacob Champion" <ch...@gmail.com> wrote:

On 05/03/2017 11:25 PM, Ruediger Pluem wrote:

> Just as a heads up as I currently don't have time to investigate further.
> I get the below on CentOS 6.9 64 bit, which
> puzzles me a little bit as I would expect the errno addresses to be
> different in different threads on my OS.
>
> [Thu May 04 06:17:13.723918 2017] [ssl:notice] [pid 2629:tid
> 140039001335552] AH10028: using deprecated
> CRYPTO_set_id_callback for OpenSSL
>
> OpenSSL used is the one delivered by CentOS: openssl-1.0.1e-57.el6.x86_64
>

Do you use an installed APR or build using --with-included-apr? The
configure test that determines whether your errno is safe has to be linked
against an already-built APR; otherwise the fallbacks come into play.


Ugh... This suggests we've further broken crosscompile, just noticed this
based on your comment.

Re: Fixing more OpenSSL callback crashes

[Jacob Champion <ch...@gmail.com>]

On 05/03/2017 11:25 PM, Ruediger Pluem wrote:
> Just as a heads up as I currently don't have time to investigate further. I get the below on CentOS 6.9 64 bit, which
> puzzles me a little bit as I would expect the errno addresses to be different in different threads on my OS.
>
> [Thu May 04 06:17:13.723918 2017] [ssl:notice] [pid 2629:tid 140039001335552] AH10028: using deprecated
> CRYPTO_set_id_callback for OpenSSL
>
> OpenSSL used is the one delivered by CentOS: openssl-1.0.1e-57.el6.x86_64

Do you use an installed APR or build using --with-included-apr? The 
configure test that determines whether your errno is safe has to be 
linked against an already-built APR; otherwise the fallbacks come into play.

--Jacob