Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of rainer.jung@kippdata.de
 designates 195.227.30.149 as permitted sender)
Message-ID: <4C4B183A.80807@kippdata.de>
Date: Sat, 24 Jul 2010 18:43:38 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [VOTE] Release httpd 2.2.16
References: <AANLkTik9RiQOUzaaaa45EV_YxxU468AQFd5Plxsf8-37@mail.gmail.com>
In-Reply-To: <AANLkTik9RiQOUzaaaa45EV_YxxU468AQFd5Plxsf8-37@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

On 21.07.2010 20:45, Paul Querna wrote:
> Test tarballs for Apache httpd 2.2.16 are available at:
>   <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
>   +/- 1
>   [+1]  Release httpd-2.2.16

+1 for release.

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

- Signature and Hashes OK
- gz and bz2 identical, no unexpected diff to svn tag
- builds fine with most and all either static or shared and
   MPMs prefork, worker, event (were applicable)
- test suite run for all those builds, no regressions from 2.2.15

Failing:

- t/apache/pr17629.t
- t/apache/pr43939.t

(see R�diger's comment about a missing backport for PR 17629 already 
contained in STATUS; no regression, I see also failure with 2.2.15 and 
2.2.14)

- t/ssl/extlookup.t
- t/ssl/require.t

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

OpenSSL version was 0.9.8o.

BTW: This should not be caused by SSL renegotiation. Both server *and* 
client use OpenSSL 0.9.8n resp. 0.9.8o and the Apache error log contains

Performing full renegotiation: complete handshake protocol (client does 
support secure renegotiation)

Regards,

Rainer