Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr 
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 "".

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  was fixed
with 92ebf6c

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

[Ivan Zhakov]

On Sat, 13 Oct 2018 at 23:37, William A Rowe Jr  wrote:
>
> On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov  wrote:
>>
>> On Sat, 13 Oct 2018 at 20:00, Gregg Smith  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

[Gregg Smith]

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(7FF8EB479000,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(7FF900589000,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  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

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 1:22 PM William A Rowe Jr 
wrote:

> On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith  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

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov  wrote:

> On Sat, 13 Oct 2018 at 20:00, Gregg Smith  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

[Ivan Zhakov]

On Sat, 13 Oct 2018 at 20:00, Gregg Smith  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

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith  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

[Gregg Smith]

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  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 
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  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 
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 
wrote:


So we kind of left this hanging...

On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  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  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 
#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

[William A Rowe Jr]

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  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 
> 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  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 
>> 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 
>> wrote:
>>
>>> So we kind of left this hanging...
>>>
>>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  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  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 
>>> #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

[William A Rowe Jr]

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  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 
> 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 
> wrote:
>
>> So we kind of left this hanging...
>>
>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  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  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 
>> #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: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

... 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 
wrote:

> So we kind of left this hanging...
>
> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  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  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 
> #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: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

So we kind of left this hanging...

On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  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  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 
#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: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

Good point.
On Jun 15, 2016 2:35 PM, "Gregg Smith"  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  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 .
>

Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Gregg Smith]

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  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 .

Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

Steffen, thanks for the confirmation about SPKI (although why Windows users
persist in using mod_php over the php-fcgi sapi is beyond me... sigh). Note
that
your hack only works when mod_php and those extensions are built with the
same clib as httpd.exe.

I am concerned that some of the functions for reading/writing certificate
CRL chains
may require this in mod_ssl.so as well. A quick review of
apr_crypto_openssl-1.dll
suggests that none of the functions we use require this stub.

It's also reassuring that others see the value of using this with all
flavors of VC,
and not simply the most problematic VS14/VS15 versions.

In building httpd.exe, some users don't build and install openssl. It isn't
going
to be possible to simply #include  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.

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?



-- Forwarded message --
From: Steffen <i...@apachelounge.com>
Date: Wed, Jun 15, 2016 at 4:39 AM
Subject: Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./
CHANGES support/ab.c
To: dev@httpd.apache.org


I do not understand your conclusion.

Background you find :  https://www.openssl.org/docs/faq.html#PROG2

Also Apachelounge includes applink shim in http.exe with all (VC10/11/14),
this is done in cooperation of the PHP dev's.

Quote:
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.

Steffen


On Wednesday 15/06/2016 at 03:33, William A Rowe Jr wrote:

Two quick observations...

Every time OpenSSL was compiled against a different CRT, whether is was a
release build of OpenSSL and a debug build of httpd/ab, or whether OpenSSL
was built under Visual Studio 2012 and httpd/ab was built against VS 2015,
this issue would occur without this patch.

Visual Studio 2015 only magnified or brought this quirk to light.

I'm curious, having seen reports of a Windows specific defect in local CRL
validation, whether this is also required in httpd.

Sadly, OpenSSL only looks for this symbol in the currently executing binary
(recall Win32 is two-level namespace)... we bind libssl/libcrypto to
libaprutil.dll and mod_ssl.so.  Exporting this from httpd.exe isn't
practical.

If that is the root of the other CRL failure observation, I'm not sure that
OpenSSL's hack is going to resolve it for our custom BIO implementation.

Gregg, if you would vet the patch as applied to trunk/2.4/2.2, I'd
appreciate it.
On Jun 14, 2016 3:37 PM, <wr...@apache.org> wrote:

Author: wrowe
Date: Tue Jun 14 20:37:52 2016
New Revision: 1748461

URL: http://svn.apache.org/viewvc?rev=1748461=rev
Log:
abs: Include OPENSSL_Applink when compiling on Windows, to resolve
failures under Visual Studio 2015 and other mismatched MSVCRT flavors.

PR: 59630
Submitted by: Jan Ehrhardt 


Modified:
httpd/httpd/branches/2.2.x/   (props changed)
httpd/httpd/branches/2.2.x/CHANGES
httpd/httpd/branches/2.2.x/support/ab.c

Propchange: httpd/httpd/branches/2.2.x/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Jun 14 20:37:52 2016
@@ -1,2 +1,2 @@
 
/httpd/httpd/branches/2.4.x:138,159,1648845,1649003,1681034,1682929,1682939,1707123,1722573,1726087
-/httpd/httpd/trunk:290940,395552,417988,451572,501364,583817,583830,611483,630858,639005,639010,647395,657354,657459,660461,660566,664330,678761,680082,681190,682369,683626,685112,686805,686809,687099,687754,693120,693392,693727-693728,696006,697093,706318,707163,708902,711421,713575,719357,720250,729316-729317,729586,732414,732504,732816,732832,733127,733134,733218-733219,734710,743589,755190,756671,756675,756678,756683,757741,761329,763394,764239,768535,769809,771587,771610,776325,777042,777091,778438-778439,778531,778942,780648,780655,780692,780697,780699,785457,785661,790587,803704,819480,823536,823563,834378,835046,891282,900022,932791,942209,952823,953311,955966,979120,981084,992625,1026743,1031551,1040304,1040373,1058192,1070096,1082189,1082196,1090645,1172732,1200040,1200372,1200374,1213380,1222335,1223048,1231446,1244211,1294306,1299738,1300171,130,1308862,1327036,1327080,1328133,1328325-1328326,1345319,1348656,1349905,1352912,1363183,1363186,1366344,1367778,1368131,136
 
8396,1369568,1395225,1398066,1400700,1408402,1410681,1413732,1414094,1416889,1418752,1422234,1422253,1435178,1447426,1470940,1475878,1476604,1476621,147

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Gregg Smith]

On 6/14/2016 6:33 PM, William A Rowe Jr wrote:

Gregg, if you would vet the patch as applied to trunk/2.4/2.2, I'd
appreciate it.
On Jun 14, 2016 3:37 PM,  wrote:
I built 2.4 and 2.2 in VC14 and tested with VC11 Openssl dlls. Being 
down a machine (with all VC runtimes from 9-14 installed) and short on 
free time that is the best I can do right now.


2.4
abs worked.
Last Changed Author: jailletc36
Last Changed Rev: 1748500

2.2
abs worked.
Last Changed Author: wrowe
Last Changed Rev: 1748461

So it looks good. I'll go over trunk in a couple days when things settle 
down on my end.

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Steffen]

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

Two quick observations...

Every time OpenSSL was compiled against a different CRT, whether is was a
release build of OpenSSL and a debug build of httpd/ab, or whether OpenSSL
was built under Visual Studio 2012 and httpd/ab was built against VS 2015,
this issue would occur without this patch.

Visual Studio 2015 only magnified or brought this quirk to light.

I'm curious, having seen reports of a Windows specific defect in local CRL
validation, whether this is also required in httpd.

Sadly, OpenSSL only looks for this symbol in the currently executing binary
(recall Win32 is two-level namespace)... we bind libssl/libcrypto to
libaprutil.dll and mod_ssl.so.  Exporting this from httpd.exe isn't
practical.

If that is the root of the other CRL failure observation, I'm not sure that
OpenSSL's hack is going to resolve it for our custom BIO implementation.

Gregg, if you would vet the patch as applied to trunk/2.4/2.2, I'd
appreciate it.
On Jun 14, 2016 3:37 PM,  wrote:

Author: wrowe
Date: Tue Jun 14 20:37:52 2016
New Revision: 1748461

URL: http://svn.apache.org/viewvc?rev=1748461=rev
Log:
abs: Include OPENSSL_Applink when compiling on Windows, to resolve
failures under Visual Studio 2015 and other mismatched MSVCRT flavors.

PR: 59630
Submitted by: Jan Ehrhardt 


Modified:
httpd/httpd/branches/2.2.x/   (props changed)
httpd/httpd/branches/2.2.x/CHANGES
httpd/httpd/branches/2.2.x/support/ab.c

Propchange: httpd/httpd/branches/2.2.x/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Jun 14 20:37:52 2016
@@ -1,2 +1,2 @@
 
/httpd/httpd/branches/2.4.x:138,159,1648845,1649003,1681034,1682929,1682939,1707123,1722573,1726087
-/httpd/httpd/trunk:290940,395552,417988,451572,501364,583817,583830,611483,630858,639005,639010,647395,657354,657459,660461,660566,664330,678761,680082,681190,682369,683626,685112,686805,686809,687099,687754,693120,693392,693727-693728,696006,697093,706318,707163,708902,711421,713575,719357,720250,729316-729317,729586,732414,732504,732816,732832,733127,733134,733218-733219,734710,743589,755190,756671,756675,756678,756683,757741,761329,763394,764239,768535,769809,771587,771610,776325,777042,777091,778438-778439,778531,778942,780648,780655,780692,780697,780699,785457,785661,790587,803704,819480,823536,823563,834378,835046,891282,900022,932791,942209,952823,953311,955966,979120,981084,992625,1026743,1031551,1040304,1040373,1058192,1070096,1082189,1082196,1090645,1172732,1200040,1200372,1200374,1213380,1222335,1223048,1231446,1244211,1294306,1299738,1300171,130,1308862,1327036,1327080,1328133,1328325-1328326,1345319,1348656,1349905,1352912,1363183,1363186,1366344,1367778,1368131,136
 
8396,1369568,1395225,1398066,1400700,1408402,1410681,1413732,1414094,1416889,1418752,1422234,1422253,1435178,1447426,1470940,1475878,1476604,1476621,1476642,1476644-1476645,1477530,1484852,1485409,1485668,1490994,1493330,1496429,1500323,1504276,1506714,1509872,1509875,1514215,1524192,1524770,1526168,1526189,1527291,1527295,1527925,1528718,1529559,1529988,1529991,1531505,1532816,1551685,1551714,1552227,1553204,1554276,1554281,1555240,155,1556428,1563420,1572092,1572198,1572543,1572611,1572630,1572655,1572663,1572668-1572671,1572896,1572911,1572967,1573224,1573229,1575400,1585090,1586745,1587594,1587639,1588851,1590509,1603156,1604353,1610207,1610311,1610491,1610501,1611165,1611169,1620932,1621453,1643537,1643543,1648840,1649001,1649043,1650310,1650320,1652929,1653997,1657897,1658765,1663647,1664205,1665215,1665218,1665625,1665721,1666363,1674056,1675533,1676654,1677462,1679182,1679470,1680895,1680900,1680942,1681037,1682923,1682937,1684513,1685345,1685347,1685349-1685350,1688274,
 1688536,1688538,1706989,1722572,1726086
+/httpd/httpd/trunk:290940,395552,417988,451572,501364,583817,583830,611483,630858,639005,639010,647395,657354,657459,660461,660566,664330,678761,680082,681190,682369,683626,685112,686805,686809,687099,687754,693120,693392,693727-693728,696006,697093,706318,707163,708902,711421,713575,719357,720250,729316-729317,729586,732414,732504,732816,732832,733127,733134,733218-733219,734710,743589,755190,756671,756675,756678,756683,757741,761329,763394,764239,768535,769809,771587,771610,776325,777042,777091,778438-778439,778531,778942,780648,780655,780692,780697,780699,785457,785661,790587,803704,819480,823536,823563,834378,835046,891282,900022,932791,942209,952823,953311,955966,979120,981084,992625,1026743,1031551,1040304,1040373,1058192,1070096,1082189,1082196,1090645,1172732,1200040,1200372,1200374,1213380,1222335,1223048,1231446,1244211,1294306,1299738,1300171,130,1308862,1327036,1327080,1328133,1328325-1328326,1345319,1348656,1349905,1352912,1363183,1363186,1366344,1367778,1368131,136