OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VOTE] Release httpd-2.4.37


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