On Fri, Oct 19, 2018 at 6:15 AM Steffen <info@xxxxxxxxxxxxxxxx> wrote:
I changed the subject ( was Re: svn commit: r1748461 - in
/httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)
William A Rowe Jr wrote: ...mod_php or other weirdness ....
What do you mean by weirdness ? Google translate shows it can be a bad
No slight intended; I'm speaking of loading binaries in-process which use
resource handles from libcrypto (libeay32 or whatever it was called) where
binaries arrive from different VC compilers or are built using different
models (/MD vs /MT).
So in the case that a user downloads perl, php, lua, etc built against
VC flavors by different open source projects, and loaded in-process
Apache.exe (httpd) binary, this stub is necessary. In the case that the
loading these different environments and modules built with the same linkage
by the same compiler, this stub is not necessary (except as noted in some
broken flavors of openssl.)
I never talked about a mod-php, as pointed before applink is needed for
phpXapache2_4.dll. The Microsoft PHP team asked (and still) me to use the
sim, they had some serious reports. Quote PHP team: Yeah, now it turned
out, that the SPKI functionality in PHP requires this shim to be in. The
functionality is available since PHP 5.6 and coupled with Apache could
result an unexpected process exit without the solution mentioned in the
OpenSSL FAQ compiled in.
phpXapache2_4.dll is the apache php module by another name.
"Some reports" may still correspond to the openssl 1.0.2g bug mentioned
in the thread. Or, what is likely going on is that SPKI binaries were
against OpenSSL using a different version of the compiler.
An other example:
mod_md errors when no applink sim, in the past AL has also reports of the
Just tested again with AH httpd-2.4.35 with Openssl 110i, and no
surprise, is does not even start, see below. Replacing the httpd.exe from
AL with the sim all fine. Looks like a module using ssl needs the sim.
This makes sense if the OpenSSL 1.1.0i is built with a different compiler
and memory model. If it is built with the same, this should be reported to
the openssl project as a bug. The BIO interfaces are used by mod_md,
so this is expected. This is likely the 1.0.2g bug.
In any case, the usage of apache allows for arbitrary modules to be loaded
and in the binaries scenario. It seems the stub should be added in
whenever mod_ssl/mod_md/aprutil have been linked to libcrypto.
This all goes against your earlier comment to me not to add this patch to
Apache.exe binary for building on Windows. You are reversing your objection?
I've seen another objection which suggests that "Apache.exe isn't even
linked to OpenSSL." What's important here is that the stub does not
invoke or link to OpenSSL at all. It simply provides an array of entry
to the current Visual Studio C Runtime, which Apache.exe is linked to,
as a shared, exported symbol that can be found by any of the .dll code
loaded in process. >
If so, based especially on mod_md and the possibility of users loading
a flavor of the libcrypto/libssl libraries which weren't created by the same
Visual Studio + memory model as when building Apache, it seems we
should proceed with patching the Apache/httpd top level binary.