You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Daniel Ruggeri <dr...@primary.net> on 2018/10/17 11:41:10 UTC
[NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Hi, all;
With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x, I would like to tag the next version of our venerable server soon.
I have already successfully completed the test suite against my "latest sources" docker environment and am watching for any smoke detected in [1]. Feeling good about this one :-)
How about roughly 24 hours from now?
[1] https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@<dev.httpd.apache.org>
--
Daniel Ruggeri
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/17/2018 03:25 PM, William A Rowe Jr wrote:
> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/ is what
> will be exported, ,/buildconf invoked, and then tarred up, if that helps
> you anticipate the tag a day early. It shouldn't give any different
> hassles than trunk.
thank you, okay. cool ... I can do a checkout.
Dennis
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/ is what will
be exported, ,/buildconf invoked, and then tarred up, if that helps you
anticipate the tag a day early. It shouldn't give any different hassles
than trunk.
On Wed, Oct 17, 2018, 13:31 Dennis Clarke <dc...@blastwave.org> wrote:
> On 10/17/2018 02:24 PM, Daniel Ruggeri wrote:
> > On 2018-10-17 13:13, Dennis Clarke wrote:
> >> On 10/17/2018 07:41 AM, Daniel Ruggeri wrote:
> >>> Hi, all;
> >>> With the fix for detected OpenSSL 1.1.1 issues now backported to
> >>> 2.4.x, I would like to tag the next version of our venerable server
> >>> soon.
> >>>
> >>> I have already successfully completed the test suite against my
> >>> "latest sources" docker environment and am watching for any smoke
> >>> detected in [1]. Feeling good about this one :-)
> >>>
> >>> How about roughly 24 hours from now?
> >>>
> >>
> >> Can we get a tarball at https://dist.apache.org/repos/dist/dev/httpd/ ?
> >>
> >> Dennis
> >
> > Hi, Dennis;
> > Yes, of course. That gets pushed shortly after the tag occurs. An
> > email will be sent to this list immediately after. I anticipate that it
> > will be there no later than 13:00 GMT tomorrow.
> >
> > If you're interested in the details, feel free to check out the release
> > documentation here:
> > http://httpd.apache.org/dev/release.html
> >
>
> Thanks .. I just wanted to get a build going. Getting trunk to work well
> with tls 1.3 was no big deal. A few hoops to jump through. However 2.4.x
> seems to have been a holy pile of hoops.
>
> Dennis
>
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/17/2018 02:24 PM, Daniel Ruggeri wrote:
> On 2018-10-17 13:13, Dennis Clarke wrote:
>> On 10/17/2018 07:41 AM, Daniel Ruggeri wrote:
>>> Hi, all;
>>> With the fix for detected OpenSSL 1.1.1 issues now backported to
>>> 2.4.x, I would like to tag the next version of our venerable server
>>> soon.
>>>
>>> I have already successfully completed the test suite against my
>>> "latest sources" docker environment and am watching for any smoke
>>> detected in [1]. Feeling good about this one :-)
>>>
>>> How about roughly 24 hours from now?
>>>
>>
>> Can we get a tarball at https://dist.apache.org/repos/dist/dev/httpd/ ?
>>
>> Dennis
>
> Hi, Dennis;
> Yes, of course. That gets pushed shortly after the tag occurs. An
> email will be sent to this list immediately after. I anticipate that it
> will be there no later than 13:00 GMT tomorrow.
>
> If you're interested in the details, feel free to check out the release
> documentation here:
> http://httpd.apache.org/dev/release.html
>
Thanks .. I just wanted to get a build going. Getting trunk to work well
with tls 1.3 was no big deal. A few hoops to jump through. However 2.4.x
seems to have been a holy pile of hoops.
Dennis
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Daniel Ruggeri <dr...@primary.net>.
On 2018-10-17 13:13, Dennis Clarke wrote:
> On 10/17/2018 07:41 AM, Daniel Ruggeri wrote:
>> Hi, all;
>> With the fix for detected OpenSSL 1.1.1 issues now backported to
>> 2.4.x, I would like to tag the next version of our venerable server
>> soon.
>>
>> I have already successfully completed the test suite against my
>> "latest sources" docker environment and am watching for any smoke
>> detected in [1]. Feeling good about this one :-)
>>
>> How about roughly 24 hours from now?
>>
>
> Can we get a tarball at https://dist.apache.org/repos/dist/dev/httpd/ ?
>
> Dennis
Hi, Dennis;
Yes, of course. That gets pushed shortly after the tag occurs. An
email will be sent to this list immediately after. I anticipate that it
will be there no later than 13:00 GMT tomorrow.
If you're interested in the details, feel free to check out the release
documentation here:
http://httpd.apache.org/dev/release.html
--
Daniel Ruggeri
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/17/2018 07:41 AM, Daniel Ruggeri wrote:
> Hi, all;
> With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x,
> I would like to tag the next version of our venerable server soon.
>
> I have already successfully completed the test suite against my "latest
> sources" docker environment and am watching for any smoke detected in
> [1]. Feeling good about this one :-)
>
> How about roughly 24 hours from now?
>
Can we get a tarball at https://dist.apache.org/repos/dist/dev/httpd/ ?
Dennis
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 17.10.2018 um 13:43 schrieb Graham Leggett <mi...@sharp.fm>:
>
> On 17 Oct 2018, at 13:41, Daniel Ruggeri <dr...@primary.net> wrote:
>
>> Hi, all;
>> With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x, I would like to tag the next version of our venerable server soon.
>>
>> I have already successfully completed the test suite against my "latest sources" docker environment and am watching for any smoke detected in [1]. Feeling good about this one :-)
>>
>> How about roughly 24 hours from now?
>
> +1.
>
> I see a flurry of openssl 1.1.1 / TLS1.3 related activity on various other tools out there (sendmail, etc), so we’re in good company.
>
+1.
Cheers, Stefan
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Graham Leggett <mi...@sharp.fm>.
On 17 Oct 2018, at 13:41, Daniel Ruggeri <dr...@primary.net> wrote:
> Hi, all;
> With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x, I would like to tag the next version of our venerable server soon.
>
> I have already successfully completed the test suite against my "latest sources" docker environment and am watching for any smoke detected in [1]. Feeling good about this one :-)
>
> How about roughly 24 hours from now?
+1.
I see a flurry of openssl 1.1.1 / TLS1.3 related activity on various other tools out there (sendmail, etc), so we’re in good company.
Regards,
Graham
—
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.10.2018 um 13:41 schrieb Daniel Ruggeri:
> Hi, all;
> With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x,
> I would like to tag the next version of our venerable server soon.
>
> I have already successfully completed the test suite against my "latest
> sources" docker environment and am watching for any smoke detected in
> [1]. Feeling good about this one :-)
>
> How about roughly 24 hours from now?
>
> [1]
> https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@<dev.httpd.apache.org>
> --
> Daniel Ruggeri
+1 and thanks!
Rainer
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.10.2018 um 13:41 schrieb Daniel Ruggeri:
> Hi, all;
> With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x,
> I would like to tag the next version of our venerable server soon.
>
> I have already successfully completed the test suite against my "latest
> sources" docker environment and am watching for any smoke detected in
> [1]. Feeling good about this one :-)
>
> How about roughly 24 hours from now?
>
> [1]
> https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@<dev.httpd.apache.org>
There's a new crash report from Michael Kaufmann about one (small)
missing mod_ssl backport that leads to crashes under certain conditions
during renegotiation. That case seems to be not covered by the test
suite. I proposed the backport a few minutes ago. This one is probably a
show-stopper.
And there's another (small) backport candidate (r1844002) that I added
to STATUS now. No crash, but missing config merging leading to
unexpected behavior for some configurations. This one is not a
regression but was introduced this year in 2.4.32.
Finally I observed during my tests for the current 2.4 head some crashes
but only on Solaris and only for statically linked httpd when the event
MPM is used (MPM still dynamically loaded). The crashes always happen
during shutdown and it looks to me as all or most of them happen during
OpenSSL deinit. I vaguely remember there was some discussion about how
to sync OpenSSL unloading between the various consumers we have, eg.
apr-util and mod_ssl. So probably there's currently no easy solution for
this. I don't know whether this is new and it does not happen always.
Not a show-stopper for me, since the crashes only happen when a child
process ends. Still an annoyance, but IMHO not critical.
Regards,
Rainer
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Daniel Ruggeri <dr...@primary.net>.
On 2018-10-18 07:12, Rainer Jung wrote:
> Am 17.10.2018 um 13:41 schrieb Daniel Ruggeri:
>> Hi, all;
>> With the fix for detected OpenSSL 1.1.1 issues now backported to
>> 2.4.x, I would like to tag the next version of our venerable server
>> soon.
>>
>> I have already successfully completed the test suite against my
>> "latest sources" docker environment and am watching for any smoke
>> detected in [1]. Feeling good about this one :-)
>>
>> How about roughly 24 hours from now?
>>
>> [1]
>> https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@<dev.httpd.apache.org>
>
> In the meantime most of my tests finished. The two small mod_ssl
> patches applied this morning were not part of the testing but seem
> simple enough to understand and should pose no risk.
>
> My testing showed:
>
> - t/ssl/ocsp.t fails in test 2 and 3 (lines 43 and 49) when the server
> is build using OpenSSL 0.9.8zh:
> Can't connect to localhost:8535 (SSL connect attempt failed because of
> handshake problems error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
> alert handshake failure)
> SSL connect attempt failed because of handshake problems
> error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
> failure at
> /shared/build/dev/httpd/install/Bundle-ApacheTest/20180911-0.9.8zh-1/rhel7.x86_64/lib/perl5/LWP/Protocol/http.pm line 50.
>
> I don't know whether that is expected for old OpenSSL, so can not
> judge on criticality.
>
> - t/modules/http2.t fails when the server is build using OpenSSL
> 0.9.8zh with the "Bad plan. You planned 52 tests..." message
> indicating, that h2 using TLS does not work. It happens on all
> platforms, but not if the client also uses OpenSSL 0.9.8zh.
>
> I don't know whether that is expected for old OpenSSL, so can not
> judge on criticality.
>
> - only once out of 68 runs on Solaris failure in t/modules/cgi.t test
> 54 in line 232. There log contents are checked and the file system is
> on NFS. Might be, that this is a timing issue in the test. Not a
> show-stopper for me.
>
> - only once out of 68 runs on Solaris failure in t/ssl/proxy.t test
> 106 in line 131. /eat_post responds with a proxy error (502) instead
> of 200 with the posted content length as the response body. Need to
> investigate but would also say not a show-stopper, because only on
> Solaris and only once.
>
> - some crashes on Solaris when building the server statically linked.
> Only with event MPM and looks like always at the end of a process
> lifetime, typically during shutdown. Maybe a problem with duplicate
> OpenSSL unloading/cleanup (apr-util plus mod_ssl). I think its a known
> problem, but no fix yet available. Since it should not happen to
> processes which are in use I would say it is more of an annoyance and
> not a show-stopper.
>
> Regards,
>
> Rainer
Thank you so much for the thorough testing. I see that the H2 failure
case makes sense based on feedback. I also suspect there is a strong
lead on the ocsp case. I'm also pleased to see the backports have
already made it into 2.4.x so I think we're good to go.
--
Daniel Ruggeri
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>
>
>> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>>
>> - t/modules/http2.t fails when the server is build using OpenSSL 0.9.8zh with the "Bad plan. You planned 52 tests..." message indicating, that h2 using TLS does not work. It happens on all platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>
>> I don't know whether that is expected for old OpenSSL, so can not judge on criticality.
>
> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support TLSv1.2 and is therefore unusable with h2. The test suite seems to be unprepared for this scenario. I will remove it after the next release. It is not worth fixing in its current form.
OK thanks, so we can ignore these failures.
Regards,
Rainer
Re: t/modules/http2.t: Run only if OpenSSL >= 1.0.0 is available
Posted by Stefan Eissing <st...@greenbytes.de>.
Thanks a lot!
> Am 22.10.2018 um 14:06 schrieb Rainer Jung <ra...@kippdata.de>:
>
> This seems to work nicely, committed in r1844546. Tests with old OpenSSL either in client or server result in TLSv1 and disable h2 tests. TLS test requests that result in TLSv1_2 or TLSv1_3 enable h2 tests.
>
> Regards,
>
> Rainer
>
> Am 22.10.2018 um 12:37 schrieb Rainer Jung:
>> I wonder whether it would be easier to check whether a TLS connection uses TLS 1.2 or later and disable the h2 test if not.
>> Nevertheless the module for checking the server version might be useful, but here I guess checking the TLS version is more appropriate.
>> But that might mean, that the test runs with OpenSSL 0.9.8zh in the client. At least I see some TLSv1.2 reuests during the test suite run even when using 0.9.8zh in the client. It ever happens with that version in the server.
>> Will look into it.
>> Regards,
>> Rainer
>> Am 21.10.2018 um 14:28 schrieb Daniel Ruggeri:
>>>
>>> On 10/21/2018 6:46 AM, Rainer Jung wrote:
>>>> Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>>>>>> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>>>>>>
>>>>>> - t/modules/http2.t fails when the server is build using OpenSSL
>>>>>> 0.9.8zh with the "Bad plan. You planned 52 tests..." message
>>>>>> indicating, that h2 using TLS does not work. It happens on all
>>>>>> platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>>>>>
>>>>>> I don't know whether that is expected for old OpenSSL, so can not
>>>>>> judge on criticality.
>>>>>
>>>>> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support
>>>>> TLSv1.2 and is therefore unusable with h2. The test suite seems to be
>>>>> unprepared for this scenario. I will remove it after the next
>>>>> release. It is not worth fixing in its current form.
>>>>
>>>> I added a check agains the test suite OpenSSL version in r1844483.
>>>>
>>>> I have an aditional check for the server version available.
>>>> Unfortunately I didn't find a really easy way, so here's a small
>>>> module that one can query
>>>> (c-modules/test_ssl_version/mod_test_ssl_version.c), mostly a
>>>> shortened form of mod_test_ssl.c:
>>>>
>>>> ==== SNIP =====
>>>> #define HTTPD_TEST_REQUIRE_APACHE 2
>>>>
>>>> #if CONFIG_FOR_HTTPD_TEST
>>>>
>>>> <IfModule @ssl_module@>
>>>> <Location /test_ssl_version_lookup>
>>>> SetHandler test-ssl-version-lookup
>>>> </Location>
>>>> </IfModule>
>>>>
>>>> #endif
>>>>
>>>> #include "httpd.h"
>>>> #include "http_config.h"
>>>> #include "http_protocol.h"
>>>> #include "http_log.h"
>>>> #include "ap_config.h"
>>>> #include "apr_optional.h"
>>>>
>>>> #if AP_MODULE_MAGIC_AT_LEAST(20040425, 0) /* simply include mod_ssl.h
>>>> if using >= 2.1.0 */
>>>>
>>>> #include "mod_ssl.h"
>>>>
>>>> #else
>>>> /* For use of < 2.0.x, inline the declaration: */
>>>>
>>>> APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup,
>>>> (apr_pool_t *, server_rec *,
>>>> conn_rec *, request_rec *,
>>>> char *));
>>>>
>>>> #endif
>>>>
>>>> static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *var_lookup;
>>>>
>>>> static void import_ssl_var_lookup(void)
>>>> {
>>>> var_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
>>>> }
>>>>
>>>> static int test_ssl_version_lookup(request_rec *r)
>>>> {
>>>> char *value;
>>>>
>>>> if (strcmp(r->handler, "test-ssl-version-lookup")) {
>>>> return DECLINED;
>>>> }
>>>>
>>>> if (r->method_number != M_GET) {
>>>> return DECLINED;
>>>> }
>>>>
>>>> if (!var_lookup) {
>>>> ap_rputs("ssl_var_lookup is not available", r);
>>>> return OK;
>>>> }
>>>>
>>>> value = var_lookup(r->pool, r->server,
>>>> r->connection, r, "SSL_VERSION_LIBRARY");
>>>>
>>>> if (value && *value) {
>>>> ap_rputs(value, r);
>>>> }
>>>> else {
>>>> ap_rputs("NULL", r);
>>>> }
>>>>
>>>> return OK;
>>>> }
>>>>
>>>> static void test_ssl_version_register_hooks(apr_pool_t *p)
>>>> {
>>>> ap_hook_handler(test_ssl_version_lookup, NULL, NULL,
>>>> APR_HOOK_MIDDLE);
>>>> ap_hook_optional_fn_retrieve(import_ssl_var_lookup,
>>>> NULL, NULL, APR_HOOK_MIDDLE);
>>>> }
>>>>
>>>> module AP_MODULE_DECLARE_DATA test_ssl_version_module = {
>>>> STANDARD20_MODULE_STUFF,
>>>> NULL, /* create per-dir config structures */
>>>> NULL, /* merge per-dir config structures */
>>>> NULL, /* create per-server config structures */
>>>> NULL, /* merge per-server config structures */
>>>> NULL, /* table of config file commands */
>>>> test_ssl_version_register_hooks /* register hooks */
>>>> };
>>>> ==== SNIP =====
>>>>
>>>> and the necessary addition to http2.t to use the module:
>>>>
>>>> Index: t/modules/http2.t
>>>> ===================================================================
>>>> --- t/modules/http2.t (revision 1844483)
>>>> +++ t/modules/http2.t (working copy)
>>>> @@ -25,6 +25,16 @@
>>>> my $openssl_version = Net::SSLeay::OPENSSL_VERSION_NUMBER();
>>>> if ($openssl_version < 0x10000000) {
>>>> $tls_modern = 0;
>>>> +} else {
>>>> + Apache::TestRequest::scheme("https");
>>>> + my $url = '/test_ssl_version_lookup';
>>>> + my $r = GET("$url");
>>>> + $openssl_version = $r->content;
>>>> + print STDOUT "OpenSSL version '$openssl_version'\n";
>>>> + # OpenSSL/0.9.8zh, OpenSSL/1.0.2p etc.
>>>> + if ($openssl_version =~ /\/0\./) {
>>>> + $tls_modern = 0;
>>>> + }
>>>> }
>>>>
>>>> Apache::TestRequest::module("http2");
>>>>
>>>> What do people think? Should I apply it?
>>>>
>>>> Regards,
>>>>
>>>> Rainer
>>>
>>> +1
Re: t/modules/http2.t: Run only if OpenSSL >= 1.0.0 is available
Posted by Rainer Jung <ra...@kippdata.de>.
This seems to work nicely, committed in r1844546. Tests with old OpenSSL
either in client or server result in TLSv1 and disable h2 tests. TLS
test requests that result in TLSv1_2 or TLSv1_3 enable h2 tests.
Regards,
Rainer
Am 22.10.2018 um 12:37 schrieb Rainer Jung:
> I wonder whether it would be easier to check whether a TLS connection
> uses TLS 1.2 or later and disable the h2 test if not.
>
> Nevertheless the module for checking the server version might be useful,
> but here I guess checking the TLS version is more appropriate.
>
> But that might mean, that the test runs with OpenSSL 0.9.8zh in the
> client. At least I see some TLSv1.2 reuests during the test suite run
> even when using 0.9.8zh in the client. It ever happens with that version
> in the server.
>
> Will look into it.
>
> Regards,
>
> Rainer
>
> Am 21.10.2018 um 14:28 schrieb Daniel Ruggeri:
>>
>> On 10/21/2018 6:46 AM, Rainer Jung wrote:
>>> Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>>>>> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>>>>>
>>>>> - t/modules/http2.t fails when the server is build using OpenSSL
>>>>> 0.9.8zh with the "Bad plan. You planned 52 tests..." message
>>>>> indicating, that h2 using TLS does not work. It happens on all
>>>>> platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>>>>
>>>>> I don't know whether that is expected for old OpenSSL, so can not
>>>>> judge on criticality.
>>>>
>>>> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support
>>>> TLSv1.2 and is therefore unusable with h2. The test suite seems to be
>>>> unprepared for this scenario. I will remove it after the next
>>>> release. It is not worth fixing in its current form.
>>>
>>> I added a check agains the test suite OpenSSL version in r1844483.
>>>
>>> I have an aditional check for the server version available.
>>> Unfortunately I didn't find a really easy way, so here's a small
>>> module that one can query
>>> (c-modules/test_ssl_version/mod_test_ssl_version.c), mostly a
>>> shortened form of mod_test_ssl.c:
>>>
>>> ==== SNIP =====
>>> #define HTTPD_TEST_REQUIRE_APACHE 2
>>>
>>> #if CONFIG_FOR_HTTPD_TEST
>>>
>>> <IfModule @ssl_module@>
>>> <Location /test_ssl_version_lookup>
>>> SetHandler test-ssl-version-lookup
>>> </Location>
>>> </IfModule>
>>>
>>> #endif
>>>
>>> #include "httpd.h"
>>> #include "http_config.h"
>>> #include "http_protocol.h"
>>> #include "http_log.h"
>>> #include "ap_config.h"
>>> #include "apr_optional.h"
>>>
>>> #if AP_MODULE_MAGIC_AT_LEAST(20040425, 0) /* simply include mod_ssl.h
>>> if using >= 2.1.0 */
>>>
>>> #include "mod_ssl.h"
>>>
>>> #else
>>> /* For use of < 2.0.x, inline the declaration: */
>>>
>>> APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup,
>>> (apr_pool_t *, server_rec *,
>>> conn_rec *, request_rec *,
>>> char *));
>>>
>>> #endif
>>>
>>> static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *var_lookup;
>>>
>>> static void import_ssl_var_lookup(void)
>>> {
>>> var_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
>>> }
>>>
>>> static int test_ssl_version_lookup(request_rec *r)
>>> {
>>> char *value;
>>>
>>> if (strcmp(r->handler, "test-ssl-version-lookup")) {
>>> return DECLINED;
>>> }
>>>
>>> if (r->method_number != M_GET) {
>>> return DECLINED;
>>> }
>>>
>>> if (!var_lookup) {
>>> ap_rputs("ssl_var_lookup is not available", r);
>>> return OK;
>>> }
>>>
>>> value = var_lookup(r->pool, r->server,
>>> r->connection, r, "SSL_VERSION_LIBRARY");
>>>
>>> if (value && *value) {
>>> ap_rputs(value, r);
>>> }
>>> else {
>>> ap_rputs("NULL", r);
>>> }
>>>
>>> return OK;
>>> }
>>>
>>> static void test_ssl_version_register_hooks(apr_pool_t *p)
>>> {
>>> ap_hook_handler(test_ssl_version_lookup, NULL, NULL,
>>> APR_HOOK_MIDDLE);
>>> ap_hook_optional_fn_retrieve(import_ssl_var_lookup,
>>> NULL, NULL, APR_HOOK_MIDDLE);
>>> }
>>>
>>> module AP_MODULE_DECLARE_DATA test_ssl_version_module = {
>>> STANDARD20_MODULE_STUFF,
>>> NULL, /* create per-dir config structures */
>>> NULL, /* merge per-dir config structures */
>>> NULL, /* create per-server config structures */
>>> NULL, /* merge per-server config structures */
>>> NULL, /* table of config file commands */
>>> test_ssl_version_register_hooks /* register hooks */
>>> };
>>> ==== SNIP =====
>>>
>>> and the necessary addition to http2.t to use the module:
>>>
>>> Index: t/modules/http2.t
>>> ===================================================================
>>> --- t/modules/http2.t (revision 1844483)
>>> +++ t/modules/http2.t (working copy)
>>> @@ -25,6 +25,16 @@
>>> my $openssl_version = Net::SSLeay::OPENSSL_VERSION_NUMBER();
>>> if ($openssl_version < 0x10000000) {
>>> $tls_modern = 0;
>>> +} else {
>>> + Apache::TestRequest::scheme("https");
>>> + my $url = '/test_ssl_version_lookup';
>>> + my $r = GET("$url");
>>> + $openssl_version = $r->content;
>>> + print STDOUT "OpenSSL version '$openssl_version'\n";
>>> + # OpenSSL/0.9.8zh, OpenSSL/1.0.2p etc.
>>> + if ($openssl_version =~ /\/0\./) {
>>> + $tls_modern = 0;
>>> + }
>>> }
>>>
>>> Apache::TestRequest::module("http2");
>>>
>>> What do people think? Should I apply it?
>>>
>>> Regards,
>>>
>>> Rainer
>>
>> +1
Re: t/modules/http2.t: Run only if OpenSSL >= 1.0.0 is available
Posted by Rainer Jung <ra...@kippdata.de>.
I wonder whether it would be easier to check whether a TLS connection
uses TLS 1.2 or later and disable the h2 test if not.
Nevertheless the module for checking the server version might be useful,
but here I guess checking the TLS version is more appropriate.
But that might mean, that the test runs with OpenSSL 0.9.8zh in the
client. At least I see some TLSv1.2 reuests during the test suite run
even when using 0.9.8zh in the client. It ever happens with that version
in the server.
Will look into it.
Regards,
Rainer
Am 21.10.2018 um 14:28 schrieb Daniel Ruggeri:
>
> On 10/21/2018 6:46 AM, Rainer Jung wrote:
>> Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>>>> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>>>>
>>>> - t/modules/http2.t fails when the server is build using OpenSSL
>>>> 0.9.8zh with the "Bad plan. You planned 52 tests..." message
>>>> indicating, that h2 using TLS does not work. It happens on all
>>>> platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>>>
>>>> I don't know whether that is expected for old OpenSSL, so can not
>>>> judge on criticality.
>>>
>>> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support
>>> TLSv1.2 and is therefore unusable with h2. The test suite seems to be
>>> unprepared for this scenario. I will remove it after the next
>>> release. It is not worth fixing in its current form.
>>
>> I added a check agains the test suite OpenSSL version in r1844483.
>>
>> I have an aditional check for the server version available.
>> Unfortunately I didn't find a really easy way, so here's a small
>> module that one can query
>> (c-modules/test_ssl_version/mod_test_ssl_version.c), mostly a
>> shortened form of mod_test_ssl.c:
>>
>> ==== SNIP =====
>> #define HTTPD_TEST_REQUIRE_APACHE 2
>>
>> #if CONFIG_FOR_HTTPD_TEST
>>
>> <IfModule @ssl_module@>
>> <Location /test_ssl_version_lookup>
>> SetHandler test-ssl-version-lookup
>> </Location>
>> </IfModule>
>>
>> #endif
>>
>> #include "httpd.h"
>> #include "http_config.h"
>> #include "http_protocol.h"
>> #include "http_log.h"
>> #include "ap_config.h"
>> #include "apr_optional.h"
>>
>> #if AP_MODULE_MAGIC_AT_LEAST(20040425, 0) /* simply include mod_ssl.h
>> if using >= 2.1.0 */
>>
>> #include "mod_ssl.h"
>>
>> #else
>> /* For use of < 2.0.x, inline the declaration: */
>>
>> APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup,
>> (apr_pool_t *, server_rec *,
>> conn_rec *, request_rec *,
>> char *));
>>
>> #endif
>>
>> static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *var_lookup;
>>
>> static void import_ssl_var_lookup(void)
>> {
>> var_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
>> }
>>
>> static int test_ssl_version_lookup(request_rec *r)
>> {
>> char *value;
>>
>> if (strcmp(r->handler, "test-ssl-version-lookup")) {
>> return DECLINED;
>> }
>>
>> if (r->method_number != M_GET) {
>> return DECLINED;
>> }
>>
>> if (!var_lookup) {
>> ap_rputs("ssl_var_lookup is not available", r);
>> return OK;
>> }
>>
>> value = var_lookup(r->pool, r->server,
>> r->connection, r, "SSL_VERSION_LIBRARY");
>>
>> if (value && *value) {
>> ap_rputs(value, r);
>> }
>> else {
>> ap_rputs("NULL", r);
>> }
>>
>> return OK;
>> }
>>
>> static void test_ssl_version_register_hooks(apr_pool_t *p)
>> {
>> ap_hook_handler(test_ssl_version_lookup, NULL, NULL,
>> APR_HOOK_MIDDLE);
>> ap_hook_optional_fn_retrieve(import_ssl_var_lookup,
>> NULL, NULL, APR_HOOK_MIDDLE);
>> }
>>
>> module AP_MODULE_DECLARE_DATA test_ssl_version_module = {
>> STANDARD20_MODULE_STUFF,
>> NULL, /* create per-dir config structures */
>> NULL, /* merge per-dir config structures */
>> NULL, /* create per-server config structures */
>> NULL, /* merge per-server config structures */
>> NULL, /* table of config file commands */
>> test_ssl_version_register_hooks /* register hooks */
>> };
>> ==== SNIP =====
>>
>> and the necessary addition to http2.t to use the module:
>>
>> Index: t/modules/http2.t
>> ===================================================================
>> --- t/modules/http2.t (revision 1844483)
>> +++ t/modules/http2.t (working copy)
>> @@ -25,6 +25,16 @@
>> my $openssl_version = Net::SSLeay::OPENSSL_VERSION_NUMBER();
>> if ($openssl_version < 0x10000000) {
>> $tls_modern = 0;
>> +} else {
>> + Apache::TestRequest::scheme("https");
>> + my $url = '/test_ssl_version_lookup';
>> + my $r = GET("$url");
>> + $openssl_version = $r->content;
>> + print STDOUT "OpenSSL version '$openssl_version'\n";
>> + # OpenSSL/0.9.8zh, OpenSSL/1.0.2p etc.
>> + if ($openssl_version =~ /\/0\./) {
>> + $tls_modern = 0;
>> + }
>> }
>>
>> Apache::TestRequest::module("http2");
>>
>> What do people think? Should I apply it?
>>
>> Regards,
>>
>> Rainer
>
> +1
Re: t/modules/http2.t: Run only if OpenSSL >= 1.0.0 is available
Posted by Daniel Ruggeri <dr...@primary.net>.
On 10/21/2018 6:46 AM, Rainer Jung wrote:
> Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>>> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>>>
>>> - t/modules/http2.t fails when the server is build using OpenSSL
>>> 0.9.8zh with the "Bad plan. You planned 52 tests..." message
>>> indicating, that h2 using TLS does not work. It happens on all
>>> platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>>
>>> I don't know whether that is expected for old OpenSSL, so can not
>>> judge on criticality.
>>
>> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support
>> TLSv1.2 and is therefore unusable with h2. The test suite seems to be
>> unprepared for this scenario. I will remove it after the next
>> release. It is not worth fixing in its current form.
>
> I added a check agains the test suite OpenSSL version in r1844483.
>
> I have an aditional check for the server version available.
> Unfortunately I didn't find a really easy way, so here's a small
> module that one can query
> (c-modules/test_ssl_version/mod_test_ssl_version.c), mostly a
> shortened form of mod_test_ssl.c:
>
> ==== SNIP =====
> #define HTTPD_TEST_REQUIRE_APACHE 2
>
> #if CONFIG_FOR_HTTPD_TEST
>
> <IfModule @ssl_module@>
> <Location /test_ssl_version_lookup>
> SetHandler test-ssl-version-lookup
> </Location>
> </IfModule>
>
> #endif
>
> #include "httpd.h"
> #include "http_config.h"
> #include "http_protocol.h"
> #include "http_log.h"
> #include "ap_config.h"
> #include "apr_optional.h"
>
> #if AP_MODULE_MAGIC_AT_LEAST(20040425, 0) /* simply include mod_ssl.h
> if using >= 2.1.0 */
>
> #include "mod_ssl.h"
>
> #else
> /* For use of < 2.0.x, inline the declaration: */
>
> APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup,
> (apr_pool_t *, server_rec *,
> conn_rec *, request_rec *,
> char *));
>
> #endif
>
> static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *var_lookup;
>
> static void import_ssl_var_lookup(void)
> {
> var_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
> }
>
> static int test_ssl_version_lookup(request_rec *r)
> {
> char *value;
>
> if (strcmp(r->handler, "test-ssl-version-lookup")) {
> return DECLINED;
> }
>
> if (r->method_number != M_GET) {
> return DECLINED;
> }
>
> if (!var_lookup) {
> ap_rputs("ssl_var_lookup is not available", r);
> return OK;
> }
>
> value = var_lookup(r->pool, r->server,
> r->connection, r, "SSL_VERSION_LIBRARY");
>
> if (value && *value) {
> ap_rputs(value, r);
> }
> else {
> ap_rputs("NULL", r);
> }
>
> return OK;
> }
>
> static void test_ssl_version_register_hooks(apr_pool_t *p)
> {
> ap_hook_handler(test_ssl_version_lookup, NULL, NULL,
> APR_HOOK_MIDDLE);
> ap_hook_optional_fn_retrieve(import_ssl_var_lookup,
> NULL, NULL, APR_HOOK_MIDDLE);
> }
>
> module AP_MODULE_DECLARE_DATA test_ssl_version_module = {
> STANDARD20_MODULE_STUFF,
> NULL, /* create per-dir config structures */
> NULL, /* merge per-dir config structures */
> NULL, /* create per-server config structures */
> NULL, /* merge per-server config structures */
> NULL, /* table of config file commands */
> test_ssl_version_register_hooks /* register hooks */
> };
> ==== SNIP =====
>
> and the necessary addition to http2.t to use the module:
>
> Index: t/modules/http2.t
> ===================================================================
> --- t/modules/http2.t (revision 1844483)
> +++ t/modules/http2.t (working copy)
> @@ -25,6 +25,16 @@
> my $openssl_version = Net::SSLeay::OPENSSL_VERSION_NUMBER();
> if ($openssl_version < 0x10000000) {
> $tls_modern = 0;
> +} else {
> + Apache::TestRequest::scheme("https");
> + my $url = '/test_ssl_version_lookup';
> + my $r = GET("$url");
> + $openssl_version = $r->content;
> + print STDOUT "OpenSSL version '$openssl_version'\n";
> + # OpenSSL/0.9.8zh, OpenSSL/1.0.2p etc.
> + if ($openssl_version =~ /\/0\./) {
> + $tls_modern = 0;
> + }
> }
>
> Apache::TestRequest::module("http2");
>
> What do people think? Should I apply it?
>
> Regards,
>
> Rainer
+1
--
Daniel Ruggeri
t/modules/http2.t: Run only if OpenSSL >= 1.0.0 is available
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>>
>> - t/modules/http2.t fails when the server is build using OpenSSL 0.9.8zh with the "Bad plan. You planned 52 tests..." message indicating, that h2 using TLS does not work. It happens on all platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>
>> I don't know whether that is expected for old OpenSSL, so can not judge on criticality.
>
> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support TLSv1.2 and is therefore unusable with h2. The test suite seems to be unprepared for this scenario. I will remove it after the next release. It is not worth fixing in its current form.
I added a check agains the test suite OpenSSL version in r1844483.
I have an aditional check for the server version available.
Unfortunately I didn't find a really easy way, so here's a small module
that one can query (c-modules/test_ssl_version/mod_test_ssl_version.c),
mostly a shortened form of mod_test_ssl.c:
==== SNIP =====
#define HTTPD_TEST_REQUIRE_APACHE 2
#if CONFIG_FOR_HTTPD_TEST
<IfModule @ssl_module@>
<Location /test_ssl_version_lookup>
SetHandler test-ssl-version-lookup
</Location>
</IfModule>
#endif
#include "httpd.h"
#include "http_config.h"
#include "http_protocol.h"
#include "http_log.h"
#include "ap_config.h"
#include "apr_optional.h"
#if AP_MODULE_MAGIC_AT_LEAST(20040425, 0) /* simply include mod_ssl.h if
using >= 2.1.0 */
#include "mod_ssl.h"
#else
/* For use of < 2.0.x, inline the declaration: */
APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup,
(apr_pool_t *, server_rec *,
conn_rec *, request_rec *,
char *));
#endif
static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *var_lookup;
static void import_ssl_var_lookup(void)
{
var_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
}
static int test_ssl_version_lookup(request_rec *r)
{
char *value;
if (strcmp(r->handler, "test-ssl-version-lookup")) {
return DECLINED;
}
if (r->method_number != M_GET) {
return DECLINED;
}
if (!var_lookup) {
ap_rputs("ssl_var_lookup is not available", r);
return OK;
}
value = var_lookup(r->pool, r->server,
r->connection, r, "SSL_VERSION_LIBRARY");
if (value && *value) {
ap_rputs(value, r);
}
else {
ap_rputs("NULL", r);
}
return OK;
}
static void test_ssl_version_register_hooks(apr_pool_t *p)
{
ap_hook_handler(test_ssl_version_lookup, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_optional_fn_retrieve(import_ssl_var_lookup,
NULL, NULL, APR_HOOK_MIDDLE);
}
module AP_MODULE_DECLARE_DATA test_ssl_version_module = {
STANDARD20_MODULE_STUFF,
NULL, /* create per-dir config structures */
NULL, /* merge per-dir config structures */
NULL, /* create per-server config structures */
NULL, /* merge per-server config structures */
NULL, /* table of config file commands */
test_ssl_version_register_hooks /* register hooks
*/
};
==== SNIP =====
and the necessary addition to http2.t to use the module:
Index: t/modules/http2.t
===================================================================
--- t/modules/http2.t (revision 1844483)
+++ t/modules/http2.t (working copy)
@@ -25,6 +25,16 @@
my $openssl_version = Net::SSLeay::OPENSSL_VERSION_NUMBER();
if ($openssl_version < 0x10000000) {
$tls_modern = 0;
+} else {
+ Apache::TestRequest::scheme("https");
+ my $url = '/test_ssl_version_lookup';
+ my $r = GET("$url");
+ $openssl_version = $r->content;
+ print STDOUT "OpenSSL version '$openssl_version'\n";
+ # OpenSSL/0.9.8zh, OpenSSL/1.0.2p etc.
+ if ($openssl_version =~ /\/0\./) {
+ $tls_modern = 0;
+ }
}
Apache::TestRequest::module("http2");
What do people think? Should I apply it?
Regards,
Rainer
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 18.10.2018 um 14:12 schrieb Rainer Jung <ra...@kippdata.de>:
>
> - t/modules/http2.t fails when the server is build using OpenSSL 0.9.8zh with the "Bad plan. You planned 52 tests..." message indicating, that h2 using TLS does not work. It happens on all platforms, but not if the client also uses OpenSSL 0.9.8zh.
>
> I don't know whether that is expected for old OpenSSL, so can not judge on criticality.
AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support TLSv1.2 and is therefore unusable with h2. The test suite seems to be unprepared for this scenario. I will remove it after the next release. It is not worth fixing in its current form.
-Stefan
Re: [NOTICE] Intent to T&R 2.4.37 - about 12:00 GMT tomorrow
Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.10.2018 um 13:41 schrieb Daniel Ruggeri:
> Hi, all;
> With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x,
> I would like to tag the next version of our venerable server soon.
>
> I have already successfully completed the test suite against my "latest
> sources" docker environment and am watching for any smoke detected in
> [1]. Feeling good about this one :-)
>
> How about roughly 24 hours from now?
>
> [1]
> https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@<dev.httpd.apache.org>
In the meantime most of my tests finished. The two small mod_ssl patches
applied this morning were not part of the testing but seem simple enough
to understand and should pose no risk.
My testing showed:
- t/ssl/ocsp.t fails in test 2 and 3 (lines 43 and 49) when the server
is build using OpenSSL 0.9.8zh:
Can't connect to localhost:8535 (SSL connect attempt failed because of
handshake problems error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure)
SSL connect attempt failed because of handshake problems
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure at
/shared/build/dev/httpd/install/Bundle-ApacheTest/20180911-0.9.8zh-1/rhel7.x86_64/lib/perl5/LWP/Protocol/http.pm
line 50.
I don't know whether that is expected for old OpenSSL, so can not judge
on criticality.
- t/modules/http2.t fails when the server is build using OpenSSL 0.9.8zh
with the "Bad plan. You planned 52 tests..." message indicating, that
h2 using TLS does not work. It happens on all platforms, but not if the
client also uses OpenSSL 0.9.8zh.
I don't know whether that is expected for old OpenSSL, so can not judge
on criticality.
- only once out of 68 runs on Solaris failure in t/modules/cgi.t test 54
in line 232. There log contents are checked and the file system is on
NFS. Might be, that this is a timing issue in the test. Not a
show-stopper for me.
- only once out of 68 runs on Solaris failure in t/ssl/proxy.t test 106
in line 131. /eat_post responds with a proxy error (502) instead of 200
with the posted content length as the response body. Need to investigate
but would also say not a show-stopper, because only on Solaris and only
once.
- some crashes on Solaris when building the server statically linked.
Only with event MPM and looks like always at the end of a process
lifetime, typically during shutdown. Maybe a problem with duplicate
OpenSSL unloading/cleanup (apr-util plus mod_ssl). I think its a known
problem, but no fix yet available. Since it should not happen to
processes which are in use I would say it is more of an annoyance and
not a show-stopper.
Regards,
Rainer