httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: [Vote] httpd 2.2.19 release
Date Sat, 21 May 2011 14:18:09 GMT
On 20.05.2011 19:17, William A. Rowe Jr. wrote:
> Candidate binaries are available from http://httpd.apache.org/dev/dist/ -
> these do not yet constitute ASF releases.  Win32 -win32-src.zip and the
> win32-x86 binary distribution will follow shortly, in the next 1.5 hrs.
> 
> This will be a 24 hour vote, which ends no later than 17:30 GMT tomorrow.
> 
>  +/-1
>  [+1]  Release httpd 2.2.19 as GA

+1 for release

Please include key "7F7214A7" (Bill) in KEYS file at
http://www.apache.org/dist/httpd/KEYS.

Please provide CHANGES_2.2 and CHANGES_2.2.19 files.


Details:

Tested on Solaris 8+10 Sparc, SuSE Linux Enterprise 10 (32Bit and
64Bit), RedHat Enterprise Linux 5 64Bit

- Signature and Hashes OK
- key "7F7214A7" missing from KEYS file
- CHANGES files missing
- gz and bz2 identical
- no unexpected diff to svn tag
- builds fine using gcc
  - out of tree
  - with "all" module set
  - with either static or shared modules
  - MPMs prefork, worker, event (where applicable)
  - dependecies apr/apu/expat/pcre/openssl:
    - 1.4.5/1.3.12/2.0.1/8.12/0.9.8r
    - all bundled
- test suite runs for all those builds
  - no test regressions w.r.t. 2.2.18


Reminder about current status of test suite:

- Failed test 1 in t/modules/filter.t at line 14
- Failed test 2 in t/ssl/extlookup.t at line 27
- Failed test 9 in t/ssl/require.t at line 44

(same as Jeff saw)

filter: no info available right now.

>From the analysis for 2.2.16 for extlookup and require:

Both fail when trying to read the OID 1.3.6.1.4.1.18060.12.0 with value
"Lemons" from the client cert "client_ok". mod_test_ssl returns NULL,
SSLRequire logs

[info] [client 127.0.0.1] Failed expression: "Lemons" in
OID("1.3.6.1.4.1.18060.12.0")

I wasn't able to find the root cause, the value seems to be in the cert
when I dump it with OpenSSL. The dump shows leading "..", which seems to
be because the value was configured DER encoded.

Joe said in 2010: "These are testing for the bug fixed in r946240 (and
should pass on the trunk), though backporting that to 2.2.x is slightly
more involved."

Regards,

Rainer

Mime
View raw message