Am 18.10.2018 um 16:36 schrieb Daniel Ruggeri:
Hi, all;
Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/
I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.37:
[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.
The computed digests of the tarball up for vote are:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
*httpd-2.4.37.tar.gz
+1 to release and thanks a ton for RM!
Summary: all OK except for
- the CVE-2009-3555.t test with OpenSSL 1.1.1
- some shutdown crashes on Solaris event when statically linked
Detailed report:
- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
except for expected deltas
Built on
- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12 (64 Bits)
- RHEL 6+7 (64 Bits)
For all platforms built
- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against external APR/APU 1.6.5/1.6.1
- using external libraries
- expat 2.2.6
- pcre 8.42
- lua 5.3.5 (compiled with LUA_COMPAT_MODULE)
- distcache 1.5.1
- libxml2 2.9.8
- libnghttp2 1.33.0
- brotli 1.0.6
- curl 7.61.1
- jansson 2.11
and
- openssl 0.9.8zh, 1.0.2p, 1.0.2, 1.0.1e, 1.0.1i, 1.1.1
- Tool chain:
- platform gcc except on Solaris
(gcc 8.2.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
- on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6
All of the 216 builds succeeded.
- compiler warnings: none
Tested for
- Solaris 10, SLES 11+12, RHEL 6+7
- MPMs prefork, worker, event
- prefork skipped on Solaris due to the accept lock problem that
leads to timeouts and thus excessive testing times in the proxy
- default and static module builds
- log level trace8
- module set reallyall
- for "reallyall" 128 modules plus MPMs
- Perl client bundle build against OpenSSL 1.1.1, 1.1.0i, 1.0.2p and 0.9.8zh
- OpenSSL linked statically and as shared library
Every OpenSSL version in the client tested with every version in the
server, not just the same version. Client and server both with OpenSSL
1.1.1 really resulted in TLS 1.3 being used in most SSL tests (after
patching the test framework, all patches are committed to svn).
The total number of test suite runs was 1178.
The following test failures were seen:
a Crashes only on Solaris and only with event MPM and static builds.
The crash seems to happen only at the end of a process, likely due
to double cleanup of OpenSSL.
b Test 154 of t/modules/include.t only and always on
Solaris.
Not a regression
Old analysis was:
This is due to a bug in the test, which uses strftime()
with a "%s" pattern that is not supported on Solaris.
Until recently the server and the test client both returned
verbatim "%s" and the test succeeded. After updating some
Perl modules for the http2 tests, the perl client even
on Solaris now supports "%s" in strftime and the test starts
to fail. It seems we have to fix the test.
c Various tests in t/apache/expr_string.t
Not a regression.
Test numbers : 6, 11, 14, 17, 20, 23, 26, 29
Happens for 47 out of about 1100 runs
(once on SLES 11, once on Solaris 10, otherwise always on RHEL6).
The failure is always on line 87, where the error_log contents
are checked. Could be due to logs written to NFS.
d Test 5 in t/modules/dav.t:
Not a regression.
Only once, this time on SLES 11.
Creation, modified and now times not in the correct order.
This seems to be a system issue, all tests done on NFS,
many tested on virtualized guests.
e I expect prefork on Solaris still to observe timeouts during
proxy tests like reported for previous versions, but didn't test
it this time due to the long test runs when the problem happens.
I started these runs right now just to be able to report,
whether the old problem is still there or has changed.
f t/security/CVE-2009-3555.t
Fails in two ways:´, the first one I am unsure about the
criticality:
- When using OpenSSL 1.1.1 in client and server, it fails
in test 4, because the attacker request actually gets processed.
For the classic pre-1.3 handshake, there's special handling
to close the connection before the attacker request gets
handled. I am not 100% sure, but it looks to me, as if this
protection is only needed if the OpenSSL library itself is not
fixed against CVE-2009-3555 as an application side workaround.
So this should not be relevant for OpenSSL 1.1.1, and instead the
test s broken there. It would be nice if this opinion
could be confirmed by others. See the CVE-2009-3555 mail thread.
- For other OpenSSL versions fails in test 3 after switching the
test suite from Net::SSL to IO::Socket::SSL. These failures are
due to interop problems between Apache::TestRequest and
IO::Socket::SSL but should be fixed by my last adjustments to
Apache::TestRequest. So these are false positives.
g t/modules/http2.t fails for client or server using OpenSSL 0.9.8(zh)
False positive.
Success is not expected for these, but they are not excluded
from running the test. I committed an exclusion for client side
OpenSSL < 1.0.0 now and have a somewhat clumsy solution for exluding
the test when the server runs on OpenSSL < 1.0.0.
h t/ssl/proxy.t once failed in test 165 on Solaris
Not observed before but extremely rare.
The actual response as a 502 instead of 200.
Will be hard to diagnose due to its non-reproducibility.
IMHO not a show-stopper.
i t/modules/buffer.t
New test.
Fails due to the perl client stopping to send more data
as soon as the first reflected bytes are received. List discussion
indicates, that sending response bytes before the end of the request
body might not be spec compliant and thus the test be a false
positive.
So apart from the CVE-2009-3555 failure for OpenSSL 1.1.1 and the
shutdown crashes on Solaris no real problems. I think CVE-2009-3555 is a
false positive and the Solaris shutdown problem is not critical, because
only for event plus static build (plus probably APU crypto enabled).
Regards,
Rainer
