Hi Jeff,
Jeff Trawick wrote [16/11/2009 12:27]:
On Mon, Nov 16, 2009 at 6:55 AM, Jeff Trawick <[email protected]> wrote:
On Mon, Nov 16, 2009 at 6:38 AM, Bill Weir <[email protected]> wrote:
Hi,
I have downloaded and built Apache-2.2.14, using the bundled apr-1.3.9. On
x86 Solaris I am seeing bad behaviour which looks very like what is
described in https://issues.apache.org/bugzilla/show_bug.cgi?id=48029 (and
maybe also https://issues.apache.org/bugzilla/show_bug.cgi?id=48030 ). As
far as I can see, these bugs are fixed in apr-1.3.10, but I can't find a
release schedule for that.
I also notice that the APR download page quotes apr-1.3.8 as the best
available version, rather than the apr-1.3.9 that is bundled with
apache-2.2.14.
So, a bit confused here. The reason I'm building Apache at all is to get a
fix for this vulnerability -
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2699 - which says
that it affects apr-1.3.8 and earlier. But apr-1.3.9 is apparently broken
as well, as discussed above, and I can't find a release schedule for
apr-1.3.10.
How should I best proceed?
* use the patches in those PRs with APR 1.3.9
* use httpd 2.2.13 with a special port_getn() interposer I wrote which
accidentally avoids the PR 48029 issue and doesn't try to fix the
theoretical problem that is related to PR 48030
** attached to this OpenSolaris forum thread:
http://opensolaris.org/jive/thread.jspa?messageID=421151
* get the Solaris kernel team to provide a kernel patch for the
bugs/design flaws that required special handling to resolve the two
PRs you quote above (okay, I'm dreaming)
I forgot the easiest work-around:
* set envvar ac_cv_func_port_create=no before running configure
Save the configure stdout and make sure you DON'T have this message:
checking for port_create... yes
Instead you should have something like
checking for port_create... no (cached)
--/--
This work-around should be fine as long as you're not using httpd's Event MPM.
Thanks for your replies. I notice you didn't respond to the question
about when apr-1.3.10 might hit the streets? :-)
My only reservation about your suggested fixes is that the Apache I'm
building is not destined just for in-house use, but is going to be
bundled with another product. If I do some patching as you suggest,
it's not clear to me how a prospective user will know that I have done
that. If they look at the Apache config they will see that it is
apache-2.2.14 with apr-1.3.9, but they won't know that it's apr-1.3.9
with additional fixes - so they might be excused for assuming it will
have the problems that apr-1.3.9 is known to have. That's why my
preferred solution is to use apr-1.3.10 when I have the option to do that.
Thanks,
--
Bill
