[ANNOUNCEMENT] Apache HTTP Server 2.2.9 Released
Apache HTTP Server 2.2.9 Released The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.2.9 of the Apache HTTP Server (Apache). This version of Apache is principally a bug and security fix release. The following potential security flaws are addressed: * CVE-2008-2364 (cve.mitre.org) mod_proxy_http: Better handling of excessive interim responses from origin server to prevent potential denial of service and high memory usage. Reported by Ryujiro Shibuya. * CVE-2007-6420 (cve.mitre.org) mod_proxy_balancer: Prevent CSRF attacks against the balancer- manager interface. We consider this release to be the best version of Apache available, and encourage users of all prior versions to upgrade. Apache HTTP Server 2.2.9 is available for download from: http://httpd.apache.org/download.cgi Apache 2.2 offers numerous enhancements, improvements, and performance boosts over the 2.0 codebase. For an overview of new features introduced since 2.0 please see: http://httpd.apache.org/docs/2.2/new_features_2_2.html Please see the CHANGES_2.2 file, linked from the download page, for a full list of changes. A condensed list, CHANGES_2.2.9 provides the complete list of changes since 2.2.8. A summary of security vulnerabilities which were addressed in the previous 2.2.8 and earlier releases is available: http://httpd.apache.org/security/vulnerabilities_22.html Apache HTTP Server 1.3.41 and 2.0.63 legacy releases are also currently available. See the appropriate CHANGES from the url above. See the corresponding CHANGES files linked from the download page. The Apache HTTP Project developers strongly encourage all users to migrate to Apache 2.2, as only limited maintenance is performed on these legacy versions. This release includes the Apache Portable Runtime (APR) version 1.3.0 bundled with the tar and zip distributions. The APR libraries libapr and libaprutil (and on Win32, libapriconv) must all be updated to ensure binary compatibility and address many known platform bugs. This release builds on and extends the Apache 2.0 API. Modules written for Apache 2.0 will need to be recompiled in order to run with Apache 2.2, and require minimal or no source code changes. http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/VERSIONING When upgrading or installing this version of Apache, please bear in mind that if you intend to use Apache with one of the threaded MPMs (other than the Prefork MPM), you must ensure that any modules you will be using (and the libraries they depend on) are thread-safe.
Re: showstopper to 1.3.1?
On 06/14/2008 10:42 PM, William A. Rowe, Jr. wrote:
Guys, if anyone is looking at this, I'll hold off from tagging a bit
longer,
as I'd rather have apr-1.3.1 address all the platform quirks we identified
in preparing 2.2.9 for release. But if I hear nothing, I'll have to
just move ahead :)
Bill
Paul Querna wrote:
On aurora.apache.org, shortly after installing the new version, we hit
a problem with apr_pollset_poll:
[Thu Jun 12 05:36:51 2008] [error] (70007)The timeout specified has
expired: apr_pollset_poll: (listen)
[Thu Jun 12 05:36:52 2008] [notice] caught SIGTERM, shutting down
If you look in worker.c, around line 687, you can see that if do a
graceful shutdown if we get an unexpected error from apr_pollset_poll.
This appears to be a regression caused by r641661:
https://svn.apache.org/viewvc?view=revrevision=641661
Which was a fix for PR 42580:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42580
This appears to be an relative edge case on Solaris 10 -- it hasn't
happened again, and it is a regression in APR, but relatively small,
so I am still +1 for httpd-2.2.9 shipping.
Is this really a regression in APR or were we just as lucky before as we
were after?
Code from httpd
rv = apr_pollset_poll(pollset, -1, numdesc, pdesc);
if (rv != APR_SUCCESS) {
if (APR_STATUS_IS_EINTR(rv)) {
continue;
}
/* apr_pollset_poll() will only return errors in
catastrophic
* circumstances. Let's try exiting gracefully, for now. */
ap_log_error(APLOG_MARK, APLOG_ERR, rv,
(const server_rec *) ap_server_conf,
apr_pollset_poll: (listen));
So we the error message logged if apr_pollset_poll returns anything different
then
APR_SUCCESS or APR_EINTR.
So lets have a look at r641661:
--- apr/apr/trunk/poll/unix/port.c 2008/03/27 00:31:21 641660
+++ apr/apr/trunk/poll/unix/port.c 2008/03/27 00:46:05 641661
@@ -295,12 +295,7 @@
if (ret == -1) {
(*num) = 0;
-if (errno == ETIME || errno == EINTR) {
-rv = APR_TIMEUP;
-}
-else {
-rv = APR_EGENERAL;
-}
+rv = apr_get_netos_error();
}
else if (nget == 0) {
rv = APR_TIMEUP;
So the code before said that if port_getn returns -1 (== fails) we return
APR_TIMEUP
if the error is ETIME or EINTR and APR_EGENERAL.
So IMHO the error message (in this IMHO the same) would have been shown with
the old
code.
What is more strange to me is that we get a timeout error ((70007)The timeout
specified has
expired: apr_pollset_poll:) even thought we called apr_pollset_poll with -1 as
timeout which
means wait indefinitely or no timeout. The implementation of apr_pollset_poll
seems to be
correct as it ensures that we supply NULL in this case to port_getn. But OTOH
the man page
for port_get / port_getn documents timeout behaviour only for port_get (setting
timeout parameter
to null means not timeout) not for port_getn. So couldn't this be a Solaris bug?
Regards
Rüdiger
Re: svn commit: r660749 - /httpd/httpd/branches/2.2.x/STATUS
On 05/28/2008 01:20 PM, Nick Kew wrote: On Tue, 27 May 2008 22:26:09 - [EMAIL PROTECTED] wrote: + rpluem says: Thanks. Sorry for being picky, but after revisiting the patch + again I ask myself how we can be sure that the chroot function is actually + present on the platform we compile. $ man chroot ... CONFORMING TO SVr4, SVID, 4.4BSD, X/OPEN. How many unix platforms support none of the above? I guess not many. So lets backport it and see if we get a bug report where this fails to build. This may also help to create a good test for detecting it correctly Would #ifdef HAVE_UNISTD_H be an appropriate wrapper for this, or could you have a unistd without chroot? I don't know. Regards Rüdiger
