You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2018/10/12 20:03:19 UTC
Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./
CHANGES support/ab.c
... and still hanging.
Rather than ApacheLounge and some others needing to patch each time,
did we conclude that we should wire in the applink.c stub into Apache.exe
as shipped by httpd project?
(I've never mixed binaries of different MSVC environments, so myself,
I don't care, but it seems to raise issues for a subset of the community.)
On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> So we kind of left this hanging...
>
> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith <gl...@gknw.net> wrote:
>
>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>> > In building httpd.exe, some users don't build and install openssl. It
>> isn't
>> > going
>> > to be possible to simply #include<openssl/applink.c> without some
>> > conditional
>> > test. OpenSSL itself is partly the culprit, for not having an
>> > APPLINK_REQUIRED
>> > style macro conditional. But we can work around this in the cmake tests.
>> >
>>
>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>> built unless there is OpenSSL present.
>>
>> > I'll look at making this a standard bit of the httpd 2.4 build. We can
>> > likely
>> > add a user-toggled flag to the os/win32/os.h?
>>
>> Seems to me this is not needed .
>>
>
> So, is the win32 community in favor of using HAVE_OPENSSL to include
> applink.c in the scope of main.c (as revised in the current ab.c sources,
> to avoid this on libressl?)
>
> There is a presumption that the crt used by libhttpd the same as libapr,
> but I think this is a reasonable connection.
>
> The entire logic to main.c should be as simple as...
>
> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
> !defined(LIBRESSL_VERSION_NUMBER)
> /* The following logic ensures we correctly glue FILE* within one CRT used
> * by the OpenSSL library build to another CRT used by the ab.exe build.
> * This became especially problematic with Visual Studio 2015.
> */
> #include <openssl/applink.c>
> #endif
>
> By inserting the structure in httpd.exe, that structure can be found by
> the openssl library, which is not true of including this in a loadable
> library such as libhttpd.dll or libaprutil-1.dll.
>
Re: Apache Win crashes with mod_md with no Applink sim
Posted by Gregg Smith <gl...@gknw.net>.
I objected earlier but am reversing my objection after looking through
applink.c and the explanation of what it does below. Worse case there's
a very small bit of unused code in httpd.exe.
Steffen tried one of my binaries and told me off-list the results so it
seems it is needed, even when httpd & openssl come from the very same vc
compiler. I use wilcard certs so cannot use mod_md to test the results
myself.
On 10/19/2018 7:29 AM, William A Rowe Jr wrote:
> On Fri, Oct 19, 2018 at 6:15 AM Steffen <in...@apachelounge.com> 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
>> word.
>>
>
> No slight intended; I'm speaking of loading binaries in-process which use
> BIO
> resource handles from libcrypto (libeay32 or whatever it was called) where
> the
> binaries arrive from different VC compilers or are built using different
> memory
> models (/MD vs /MT).
>
> So in the case that a user downloads perl, php, lua, etc built against
> different
> VC flavors by different open source projects, and loaded in-process
> underneath
> Apache.exe (httpd) binary, this stub is necessary. In the case that the
> user is
> 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
> compiled
> 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
>> issue.
>> 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
> Apache.exe
> 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
> the
> 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
> points
> 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.
>
Re: Apache Win crashes with mod_md with no Applink sim
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Oct 19, 2018 at 6:15 AM Steffen <in...@apachelounge.com> 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
> word.
>
No slight intended; I'm speaking of loading binaries in-process which use
BIO
resource handles from libcrypto (libeay32 or whatever it was called) where
the
binaries arrive from different VC compilers or are built using different
memory
models (/MD vs /MT).
So in the case that a user downloads perl, php, lua, etc built against
different
VC flavors by different open source projects, and loaded in-process
underneath
Apache.exe (httpd) binary, this stub is necessary. In the case that the
user is
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
compiled
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
> issue.
> 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
Apache.exe
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
the
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
points
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.
Apache Win crashes with mod_md with no Applink sim
Posted by Steffen <in...@apachelounge.com>.
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 word.
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.
I mentioned already back in 2016, so I cannot stipulate enough to you
that applink sim is needed. Of course no reports on AL, because applink
is in for years.
An other example:
mod_md errors when no applink sim, in the past AL has also reports of
the issue.
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.
And for abs.exe, leave it in, does not harm and we are on the save side.
Regards,
Steffen
run with AH: httpd-2.4.35-o110i-x64-vc14.zip, Apache does not start
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464]
mod_md.c(1012): AH10070: initializing post config dry run
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464]
mod_md.c(357): AH10037: server seems not reachable via http: (port
80->80) and reachable via https: (port 443->443)
[Mon Oct 15 15:05:01.883939 2018] [md:warn] [pid 6796:tid 464] AH10045:
No VirtualHost matches Managed Domain vosadministraties.nl
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464]
mod_md.c(389): AH10039: Completed MD[vosadministraties.nl,
CA=https://acme-v01.api.letsencrypt.org/directory, Proto=ACME,
Agreement=(null), Drive=1, renew=2134720512]
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464]
md_reg.c(706): sync: found 1 mds in store
[Mon Oct 15 15:05:01.883939 2018] [md:debug] [pid 6796:tid 464]
md_reg.c(793): apachelounge.nl: update renew norm=2109194240,
window=2134720512
OPENSSL_Uplink(00007FFB73F334C8,08): no OPENSSL_Applink
On 17-10-18 18:17, William A Rowe Jr wrote:
> On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr <wrowe@rowe-clan.net
> <ma...@rowe-clan.net>> wrote:
>
> Great, I'll proceed with changing ab.c to remove the hack, since
> it is unneeded when ab.c is compiled by the same toolchain as
> libcrypto.dll, isn't available in non-openssl distributions, and
> was deprecated in 1.1.1 again.
>
>
> Note, I'll only proceed to remove the hack from trunk. I see no reason
> to make any cosmetic or build changes to 2.4.x branch. Any fallout to
> the trunk change will be uncovered in alpha/beta review. If we are
> unwilling to support the feature in httpd.exe we should not do so for
> ab.c either. (IIRC there was some subtle lingering BIO usage from
> mod_ssl for the initialization phase.)
>
> Anyone who wants to enable the applink stub logic for mod_php or other
> weirdness is welcome to patch that either by 1) adding the applink.c
> to abs.exe and/or httpd.exe linkage, or the main() source file can
> #include that "<include/openssl/applink.c>".
>
> Anyone interested can proceed to patch both and provision
> applink.c when working with OpenSSL 1.1.1, so I don't need to
> raise a ticket at that project.
>
>
> Regression #7396 <https://github.com/openssl/openssl/issues/7396> was
> fixed with 92ebf6c
> <https://github.com/openssl/openssl/commit/92ebf6c4c21ff4b41ba1fd69af74b2039e138114> for
> OpenSSL 1.1.1a. The oversight of dropping applink.c appears to have
> been unintended.
>
> Thanks to you all for your review and re-evaluation of the past and
> current situations with OpenSSL.
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> Great, I'll proceed with changing ab.c to remove the hack, since it is
> unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
> isn't available in non-openssl distributions, and was deprecated in 1.1.1
> again.
>
Note, I'll only proceed to remove the hack from trunk. I see no reason to
make any cosmetic or build changes to 2.4.x branch. Any fallout to the
trunk change will be uncovered in alpha/beta review. If we are unwilling to
support the feature in httpd.exe we should not do so for ab.c either. (IIRC
there was some subtle lingering BIO usage from mod_ssl for the
initialization phase.)
Anyone who wants to enable the applink stub logic for mod_php or other
weirdness is welcome to patch that either by 1) adding the applink.c to
abs.exe and/or httpd.exe linkage, or the main() source file can #include
that "<include/openssl/applink.c>".
Anyone interested can proceed to patch both and provision applink.c when
> working with OpenSSL 1.1.1, so I don't need to raise a ticket at that
> project.
>
Regression #7396 <https://github.com/openssl/openssl/issues/7396> was fixed
with 92ebf6c
<https://github.com/openssl/openssl/commit/92ebf6c4c21ff4b41ba1fd69af74b2039e138114>
for
OpenSSL 1.1.1a. The oversight of dropping applink.c appears to have been
unintended.
Thanks to you all for your review and re-evaluation of the past and current
situations with OpenSSL.
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Oct 13, 2018 at 1:22 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith <gl...@gknw.net> wrote:
>
>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>> > Otherwise, I understand this to be a noop.
>>
>
>> No, it just got moved to the ms folder is all that happened at 1.1.0 and
>> is still there in 1.1.1.
>>
>
> No, I'm certain that's incorrect. It was always in ms/ in the source bundle
> and was previously installed into include/openssl/ on applicable platforms.
> The fact that it isn't in the resulting installed -devel tree suggests it
> is no
> longer recommended, or that the openssl maintainers got the refactoring
> of their build schema wrong.
>
Just to carve out this single aspect of the discussion, I've logged a
ticket
with openssl about the absence of include/openssl/applink.c;
https://github.com/openssl/openssl/issues/7396
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES
support/ab.c
Posted by Gregg Smith <gl...@gknw.net>.
No, sorry I am still confused on just which we're talking about here,
support/main.c or ab.c (which I was thinking) or both? Looking over this
thread on and off list seems to be a merge of both. So because of that;
-1 to adding to applink to support/main.c. httpd.exe isn't even linked
to ossl.
For abs.exe specifically, this all started here:
https://www.apachelounge.com/viewtopic.php?t=7134
and continued in PR 59630.
I just tested a AH vc14 build of 2.4.20 from 4/2016 and
C:\Apache24\bin>abs https://google.com/
OPENSSL_Uplink(00007FF8EB479000,08): no OPENSSL_Applink
So it was a problem at one time. Today I did a vc14 x64 builds of
current abs with the include line for applink commented out for all
current ossl versions and none of the three fail.
Then I did a 2.4.20 build with ossl 1.0.2p and no error. Next one with
1.0.2p and apr/u 1.5.x (as the 4/2016 build was) and again no fail. Next
apr/u 1.5 and ossl 1.0.2g (exact same as the 4/2016 build) and
C:\Apache24\bin>abs http://google.com/
OPENSSL_Uplink(00007FF900589000,08): no OPENSSL_Applink
So Bill as you eluded to somwhere in all the tl;dr in this thread you
are correct and openssl was the problem and it does seem fixed now.
Spending much of my day on this I've found applink.c began in 0.9.8. I
think it's always been in the ms folder and just copied to
include(inc32)/openssl during the building process.
So knowing all this I'm now +1 on removing the applink include in ab.c.
Cheers
On 10/13/2018 11:22 AM, William A Rowe Jr wrote:
> On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith <gl...@gknw.net> wrote:
>
>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>>> Sorry, I don't understand.
>>>
>>> Gregg, can you shed some insight here? For both, applink.c is helpful if
>>> the OpenSSL .dll files are created with a different VC compiler than
>>> abs.exe was compiled with.
>>
>> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
>> it will still err even if both ab.c & OSSL are compiled with the same VC
>> version (14 & 15). I never tested 1.1.0.
>>
>
> I can assure you that was not true, having built against 0.9.7, .8, 1.0.0,
> etc etc etc. What can break is that if you build openssl in a different
> model
> (the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed.
>
> Can you find me any pointers to the claim that I could investigate further?
>
>> .exe, it cannot be found from a .dll or Apache .so loadable.module.
>>> Otherwise, I understand this to be a noop.
>>
>> No, it just got moved to the ms folder is all that happened at 1.1.0 and
>> is still there in 1.1.1.
>>
>
> No, I'm certain that's incorrect. It was always in ms/ in the source bundle
> and was previously installed into include/openssl/ on applicable platforms.
> The fact that it isn't in the resulting installed -devel tree suggests it
> is no
> longer recommended, or that the openssl maintainers got the refactoring
> of their build schema wrong.
>
>
>> I'm -1 on this till at least the majority of OSSL versions do not
>> include applink.c.
>>
>
> I read this as logical converse, you are +1 to patch main.c to include it?
>
> This suggests we need to re-raise the issue at the openssl project or
> declare 1.1.1 incompatible without the workaround of finding the library
> source bundle, or manually installing applink.c where it used to be.
>
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith <gl...@gknw.net> wrote:
> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
> > Sorry, I don't understand.
> >
> > Gregg, can you shed some insight here? For both, applink.c is helpful if
> > the OpenSSL .dll files are created with a different VC compiler than
> > abs.exe was compiled with.
>
> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
> it will still err even if both ab.c & OSSL are compiled with the same VC
> version (14 & 15). I never tested 1.1.0.
>
I can assure you that was not true, having built against 0.9.7, .8, 1.0.0,
etc etc etc. What can break is that if you build openssl in a different
model
(the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed.
Can you find me any pointers to the claim that I could investigate further?
> .exe, it cannot be found from a .dll or Apache .so loadable.module.
> > Otherwise, I understand this to be a noop.
>
> No, it just got moved to the ms folder is all that happened at 1.1.0 and
> is still there in 1.1.1.
>
No, I'm certain that's incorrect. It was always in ms/ in the source bundle
and was previously installed into include/openssl/ on applicable platforms.
The fact that it isn't in the resulting installed -devel tree suggests it
is no
longer recommended, or that the openssl maintainers got the refactoring
of their build schema wrong.
> I'm -1 on this till at least the majority of OSSL versions do not
> include applink.c.
>
I read this as logical converse, you are +1 to patch main.c to include it?
This suggests we need to re-raise the issue at the openssl project or
declare 1.1.1 incompatible without the workaround of finding the library
source bundle, or manually installing applink.c where it used to be.
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sat, 13 Oct 2018 at 23:37, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On Sat, 13 Oct 2018 at 20:00, Gregg Smith <gl...@gknw.net> wrote:
>>>
>>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>>> > Sorry, I don't understand.
>>> >
>>> > Gregg, can you shed some insight here? For both, applink.c is helpful if
>>> > the OpenSSL .dll files are created with a different VC compiler than
>>> > abs.exe was compiled with.
>>>
>>> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
>>> it will still err even if both ab.c & OSSL are compiled with the same VC
>>> version (14 & 15). I never tested 1.1.0.
>>>
>> That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и application uses same VC toolchain.
>
>
> That's very interesting, not observed here. Second request... pointers please?
https://github.com/openssl/openssl/blob/32f803d88ec3df7f95dfbf840c271f7438ce3357/NOTES.WIN#L137:
[[[
If you link with OpenSSL .DLLs, then you're expected to include into
your application code small "shim" snippet, which provides glue
between OpenSSL BIO layer and your compiler run-time. See the
OPENSSL_Applink manual page for further details.
]]]
In case of abs.exe problem is triggered by call to BIO_new_fp() which
sets flag BIO_FLAGS_UPLINK [1]. Then BIO_read() invokes UP_fread() try
to find OpenSSL_AppLink in the application module (!) and aborts if
function is not found.
[1] https://github.com/openssl/openssl/blob/32f803d88ec3df7f95dfbf840c271f7438ce3357/crypto/bio/bss_file.c#L103
>
> I'm strongly suspecting an /MD /MT mismatch. I only build the 'ntdll' style of OpenSSL, and never bother to mix linkage models or build abs.c static against openssl etc. Or perhaps this speaks to specific, buggy releases of 1.0.2?
>
> [Something for the audience; applink.c redirects all of the "standard c library" API's used by OpenSSL into the flavor in use by the version of the MSVC runtime linked to the primary .exe file. And in it's absence, the flavor OpenSSL was built against. Why we almost never care? These apply to basic input/output, the BIO layer of OpenSSL, which mod_ssl hardly touches. But apps using classic C stdio functionality like ab.c care a great deal. Which leads us to Ivan's comment;]
>
>>
>> Alternative solution to including applink.c could stop using OpenSSL APIs that uses stdio and provide APR based BIO implementation. In this case OpenSSL will never use stdio functions.
>
>
> Indeed! That's a complete solution. But a lot of effort if Boring/Libre/etc "just work" and only OpenSSL falls down on doing the simplest BIO functions. I'd have to fault OpenSSL, and not promote workarounds. Again I need some citations about the "defect" which makes zero sense here.
>
>> It would also support building mod_ssl with OpenSSL compiled with option --no-stdio.
>
>
> Indeed, I'm shocked if we can't build mod_ssl with --no-stdio today! Those would be some odd quirks in mod_ssl/openssl (discounting ab.c)... but that's certainly another thread. It seems like a worthwhile goal, nothing should speak stdio within mod_ssl's structure.
>
--
Ivan Zhakov
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Sat, 13 Oct 2018 at 20:00, Gregg Smith <gl...@gknw.net> wrote:
>
>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>> > Sorry, I don't understand.
>> >
>> > Gregg, can you shed some insight here? For both, applink.c is helpful if
>> > the OpenSSL .dll files are created with a different VC compiler than
>> > abs.exe was compiled with.
>>
>> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
>> it will still err even if both ab.c & OSSL are compiled with the same VC
>> version (14 & 15). I never tested 1.1.0.
>>
>> That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и
> application uses same VC toolchain.
>
That's very interesting, not observed here. Second request... pointers
please? I'm strongly suspecting an /MD /MT mismatch. I only build the
'ntdll' style of OpenSSL, and never bother to mix linkage models or build
abs.c static against openssl etc. Or perhaps this speaks to specific, buggy
releases of 1.0.2?
[Something for the audience; applink.c redirects all of the "standard c
library" API's used by OpenSSL into the flavor in use by the version of the
MSVC runtime linked to the primary .exe file. And in it's absence, the
flavor OpenSSL was built against. Why we almost never care? These apply to
basic input/output, the BIO layer of OpenSSL, which mod_ssl hardly touches.
But apps using classic C stdio functionality like ab.c care a great deal.
Which leads us to Ivan's comment;]
> Alternative solution to including applink.c could stop using OpenSSL APIs
> that uses stdio and provide APR based BIO implementation. In this case
> OpenSSL will never use stdio functions.
>
Indeed! That's a complete solution. But a lot of effort if Boring/Libre/etc
"just work" and only OpenSSL falls down on doing the simplest BIO
functions. I'd have to fault OpenSSL, and not promote workarounds. Again I
need some citations about the "defect" which makes zero sense here.
It would also support building mod_ssl with OpenSSL compiled with option
> --no-stdio.
>
Indeed, I'm shocked if we can't build mod_ssl with --no-stdio today! Those
would be some odd quirks in mod_ssl/openssl (discounting ab.c)... but
that's certainly another thread. It seems like a worthwhile goal, nothing
should speak stdio within mod_ssl's structure.
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sat, 13 Oct 2018 at 20:00, Gregg Smith <gl...@gknw.net> wrote:
> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
> > Sorry, I don't understand.
> >
> > Gregg, can you shed some insight here? For both, applink.c is helpful if
> > the OpenSSL .dll files are created with a different VC compiler than
> > abs.exe was compiled with.
>
> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
> it will still err even if both ab.c & OSSL are compiled with the same VC
> version (14 & 15). I never tested 1.1.0.
>
> That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и
application uses same VC toolchain.
Alternative solution to including applink.c could stop using OpenSSL APIs
that uses stdio and provide APR based BIO implementation. In this case
OpenSSL will never use stdio functions. It would also support building
mod_ssl with OpenSSL compiled with option --no-stdio.
--
Ivan Zhakov
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES
support/ab.c
Posted by Gregg Smith <gl...@gknw.net>.
On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
> Sorry, I don't understand.
>
> Gregg, can you shed some insight here? For both, applink.c is helpful if
> the OpenSSL .dll files are created with a different VC compiler than
> abs.exe was compiled with.
Not true, OSSL 1.0.2 I know from experience if applink.c is not included
it will still err even if both ab.c & OSSL are compiled with the same VC
version (14 & 15). I never tested 1.1.0.
> .exe, it cannot be found from a .dll or Apache .so loadable.module.
> Otherwise, I understand this to be a noop.
No, it just got moved to the ms folder is all that happened at 1.1.0 and
is still there in 1.1.1.
I'm -1 on this till at least the majority of OSSL versions do not
include applink.c.
>
> OpenSSL project deprecated, that is, no longer ships applink.c in
> include/openssl/ install directory. LibreSSL and BoringSSL have no such
> resource.
>
> Since you indicate that patching is trivial, and building with two
> different compilers isn't something an open source project should fret
> about, the Apache.exe and abs.exe should behave the same way. Pick one.
>
>
> On Sat, Oct 13, 2018, 04:04 Steffen <in...@apachelounge.com> wrote:
>
>> Do not understand your writing.
>>
>> abs.exe needs the applink shim, so leave it in.
>>
>>
>> Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr <wr...@rowe-clan.net>
>> het volgende geschreven:
>>
>> Great, I'll proceed with changing ab.c to remove the hack, since it is
>> unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
>> isn't available in non-openssl distributions, and was deprecated in 1.1.1
>> again.
>>
>> Anyone interested can proceed to patch both and provision applink.c when
>> working with OpenSSL 1.1.1, so I don't need to raise a ticket that project
>>
>>
>> On Fri, Oct 12, 2018, 16:37 Steffen <in...@apachelounge.com> wrote:
>>
>>> Already for years we have in server/main.c :
>>>
>>> #include "applink.c"
>>>
>>>
>>> This solves errors like: no OPENSSL_Applink , see for example :
>>> https://www.apachelounge.com/viewtopic.php?p=30986
>>>
>>> No problem to patch.
>>>
>>> Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr <wr...@rowe-clan.net>
>>> het volgende geschreven:
>>>
>>> ... and still hanging.
>>>
>>> Rather than ApacheLounge and some others needing to patch each time,
>>> did we conclude that we should wire in the applink.c stub into Apache.exe
>>> as shipped by httpd project?
>>>
>>> (I've never mixed binaries of different MSVC environments, so myself,
>>> I don't care, but it seems to raise issues for a subset of the community.)
>>>
>>>
>>> On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr <wr...@rowe-clan.net>
>>> wrote:
>>>
>>>> So we kind of left this hanging...
>>>>
>>>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith <gl...@gknw.net> wrote:
>>>>
>>>>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>>>>>> In building httpd.exe, some users don't build and install openssl. It
>>>>> isn't
>>>>>> going
>>>>>> to be possible to simply #include<openssl/applink.c> without some
>>>>>> conditional
>>>>>> test. OpenSSL itself is partly the culprit, for not having an
>>>>>> APPLINK_REQUIRED
>>>>>> style macro conditional. But we can work around this in the cmake
>>>>> tests.
>>>>>>
>>>>>
>>>>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>>>>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>>>>> built unless there is OpenSSL present.
>>>>>
>>>>>> I'll look at making this a standard bit of the httpd 2.4 build. We can
>>>>>> likely
>>>>>> add a user-toggled flag to the os/win32/os.h?
>>>>>
>>>>> Seems to me this is not needed .
>>>>>
>>>>
>>>> So, is the win32 community in favor of using HAVE_OPENSSL to include
>>>> applink.c in the scope of main.c (as revised in the current ab.c sources,
>>>> to avoid this on libressl?)
>>>>
>>>> There is a presumption that the crt used by libhttpd the same as libapr,
>>>> but I think this is a reasonable connection.
>>>>
>>>> The entire logic to main.c should be as simple as...
>>>>
>>>> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
>>>> !defined(LIBRESSL_VERSION_NUMBER)
>>>> /* The following logic ensures we correctly glue FILE* within one CRT
>>>> used
>>>> * by the OpenSSL library build to another CRT used by the ab.exe build.
>>>> * This became especially problematic with Visual Studio 2015.
>>>> */
>>>> #include <openssl/applink.c>
>>>> #endif
>>>>
>>>> By inserting the structure in httpd.exe, that structure can be found by
>>>> the openssl library, which is not true of including this in a loadable
>>>> library such as libhttpd.dll or libaprutil-1.dll.
>>>>
>>>
>
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Sorry, I don't understand.
Gregg, can you shed some insight here? For both, applink.c is helpful if
the OpenSSL .dll files are created with a different VC compiler than
abs.exe was compiled with. And it is only effective if compiled into the
.exe, it cannot be found from a .dll or Apache .so loadable.module.
Otherwise, I understand this to be a noop.
OpenSSL project deprecated, that is, no longer ships applink.c in
include/openssl/ install directory. LibreSSL and BoringSSL have no such
resource.
Since you indicate that patching is trivial, and building with two
different compilers isn't something an open source project should fret
about, the Apache.exe and abs.exe should behave the same way. Pick one.
On Sat, Oct 13, 2018, 04:04 Steffen <in...@apachelounge.com> wrote:
> Do not understand your writing.
>
> abs.exe needs the applink shim, so leave it in.
>
>
> Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr <wr...@rowe-clan.net>
> het volgende geschreven:
>
> Great, I'll proceed with changing ab.c to remove the hack, since it is
> unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
> isn't available in non-openssl distributions, and was deprecated in 1.1.1
> again.
>
> Anyone interested can proceed to patch both and provision applink.c when
> working with OpenSSL 1.1.1, so I don't need to raise a ticket that project
>
>
> On Fri, Oct 12, 2018, 16:37 Steffen <in...@apachelounge.com> wrote:
>
>> Already for years we have in server/main.c :
>>
>> #include "applink.c"
>>
>>
>> This solves errors like: no OPENSSL_Applink , see for example :
>> https://www.apachelounge.com/viewtopic.php?p=30986
>>
>> No problem to patch.
>>
>> Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr <wr...@rowe-clan.net>
>> het volgende geschreven:
>>
>> ... and still hanging.
>>
>> Rather than ApacheLounge and some others needing to patch each time,
>> did we conclude that we should wire in the applink.c stub into Apache.exe
>> as shipped by httpd project?
>>
>> (I've never mixed binaries of different MSVC environments, so myself,
>> I don't care, but it seems to raise issues for a subset of the community.)
>>
>>
>> On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>>
>>> So we kind of left this hanging...
>>>
>>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith <gl...@gknw.net> wrote:
>>>
>>>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>>>> > In building httpd.exe, some users don't build and install openssl. It
>>>> isn't
>>>> > going
>>>> > to be possible to simply #include<openssl/applink.c> without some
>>>> > conditional
>>>> > test. OpenSSL itself is partly the culprit, for not having an
>>>> > APPLINK_REQUIRED
>>>> > style macro conditional. But we can work around this in the cmake
>>>> tests.
>>>> >
>>>>
>>>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>>>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>>>> built unless there is OpenSSL present.
>>>>
>>>> > I'll look at making this a standard bit of the httpd 2.4 build. We can
>>>> > likely
>>>> > add a user-toggled flag to the os/win32/os.h?
>>>>
>>>> Seems to me this is not needed .
>>>>
>>>
>>> So, is the win32 community in favor of using HAVE_OPENSSL to include
>>> applink.c in the scope of main.c (as revised in the current ab.c sources,
>>> to avoid this on libressl?)
>>>
>>> There is a presumption that the crt used by libhttpd the same as libapr,
>>> but I think this is a reasonable connection.
>>>
>>> The entire logic to main.c should be as simple as...
>>>
>>> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
>>> !defined(LIBRESSL_VERSION_NUMBER)
>>> /* The following logic ensures we correctly glue FILE* within one CRT
>>> used
>>> * by the OpenSSL library build to another CRT used by the ab.exe build.
>>> * This became especially problematic with Visual Studio 2015.
>>> */
>>> #include <openssl/applink.c>
>>> #endif
>>>
>>> By inserting the structure in httpd.exe, that structure can be found by
>>> the openssl library, which is not true of including this in a loadable
>>> library such as libhttpd.dll or libaprutil-1.dll.
>>>
>>
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Great, I'll proceed with changing ab.c to remove the hack, since it is
unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
isn't available in non-openssl distributions, and was deprecated in 1.1.1
again.
Anyone interested can proceed to patch both and provision applink.c when
working with OpenSSL 1.1.1, so I don't need to raise a ticket at that
project.
On Fri, Oct 12, 2018, 16:37 Steffen <in...@apachelounge.com> wrote:
> Already for years we have in server/main.c :
>
> #include "applink.c"
>
>
> This solves errors like: no OPENSSL_Applink , see for example :
> https://www.apachelounge.com/viewtopic.php?p=30986
>
> No problem to patch.
>
> Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr <wr...@rowe-clan.net>
> het volgende geschreven:
>
> ... and still hanging.
>
> Rather than ApacheLounge and some others needing to patch each time,
> did we conclude that we should wire in the applink.c stub into Apache.exe
> as shipped by httpd project?
>
> (I've never mixed binaries of different MSVC environments, so myself,
> I don't care, but it seems to raise issues for a subset of the community.)
>
>
> On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
>> So we kind of left this hanging...
>>
>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith <gl...@gknw.net> wrote:
>>
>>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>>> > In building httpd.exe, some users don't build and install openssl. It
>>> isn't
>>> > going
>>> > to be possible to simply #include<openssl/applink.c> without some
>>> > conditional
>>> > test. OpenSSL itself is partly the culprit, for not having an
>>> > APPLINK_REQUIRED
>>> > style macro conditional. But we can work around this in the cmake
>>> tests.
>>> >
>>>
>>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>>> built unless there is OpenSSL present.
>>>
>>> > I'll look at making this a standard bit of the httpd 2.4 build. We can
>>> > likely
>>> > add a user-toggled flag to the os/win32/os.h?
>>>
>>> Seems to me this is not needed .
>>>
>>
>> So, is the win32 community in favor of using HAVE_OPENSSL to include
>> applink.c in the scope of main.c (as revised in the current ab.c sources,
>> to avoid this on libressl?)
>>
>> There is a presumption that the crt used by libhttpd the same as libapr,
>> but I think this is a reasonable connection.
>>
>> The entire logic to main.c should be as simple as...
>>
>> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
>> !defined(LIBRESSL_VERSION_NUMBER)
>> /* The following logic ensures we correctly glue FILE* within one CRT used
>> * by the OpenSSL library build to another CRT used by the ab.exe build.
>> * This became especially problematic with Visual Studio 2015.
>> */
>> #include <openssl/applink.c>
>> #endif
>>
>> By inserting the structure in httpd.exe, that structure can be found by
>> the openssl library, which is not true of including this in a loadable
>> library such as libhttpd.dll or libaprutil-1.dll.
>>
>