Re: svn commit: r952007 - /httpd/httpd/trunk/acinclude.m4
On Sun, Jun 6, 2010 at 6:05 PM, rj...@apache.org wrote: Author: rjung Date: Sun Jun 6 22:05:17 2010 New Revision: 952007 URL: http://svn.apache.org/viewvc?rev=952007view=rev Log: make shared moduled and module set most the default. Static building can be achieved with --enable-mods-static or as previously using --enable-MODULE=static. The existing --enable-mods-shared still works for compatibility with existing build scripts. I just stumbled on this 2.4 difference. If someone passes --enable-mods-shared=foo bar baz do you think module_selection should be reset? Currently you get the union of most and what you selected.
Re: [PATCH] ap_pregsub_ex and somewhat-limited ap_pregsub() to 2.2.x branch
On Fri, Jun 21, 2013 at 2:43 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On Fri, 21 Jun 2013 13:19:36 -0400 Jeff Trawick traw...@gmail.com wrote: Even with the CVE-2011-3607 it is still possible to DOS the server by consuming huge amounts of memory with mod_setenvif using a specially crafted configuration. Here's a backport of an existing fix in 2.4.x which resolves the issue I reproduced. Note that unlike in 2.4.x we need ap_pregsub to handle somewhat arbitrary string lengths. I picked 64MB, which can be overridden at compile time. http://people.apache.org/~trawick/ap_pregsub_ex_22x.txt This is essentially a grab of ap_pregsub/ap_pregsub_ex from 2.4.x HEAD with the minimal required changes plus http://svn.apache.org/viewvc?view=revisionrevision=1198966 See the XXX notes in the patch for apparent semantic changes which I probably need to back out. (I haven't researched that yet.) Normally we use STATUS to track this but I don't think it is as polished as we normally expect. Still to do (tomorrow?): Investigate the XXX's, run the regression suite. Concerns with the patch? Interested in any of this in the final 2.0.x release? I am happy to hold up a short while to adopt this patch. I'm neutral on adding it to 2.0.x but will certainly pause for it to be committed if others agree and will review the 2.0.x backport. I'm not motivated to put it in 2.0.x either, but if anyone has time to play I will assist if I can. I have a new patch -- http://people.apache.org/~trawick/ap_pregsub_ex_22x-2.txt -- which resolves the XXX's by removing Stefan's semantic changes for 2.4.x, revisions 904765 and 1307067. The previous patch has been renamed to http://people.apache.org/~trawick/ap_pregsub_ex_22x-bad.txt. The code looks good to me now, but I need to spend a little time getting more tests to run on 2.2.x and compare the failures I'm seeing with unmodified 2.2.x HEAD, and verify that ap_pregsub_ex() is working*. At that point I will move it to 2.2.x/STATUS. *2.4.x's mod_substitute uses ap_pregsub_ex(), but that is wrapped up in a lot of other changes. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: svn commit: r952007 - /httpd/httpd/trunk/acinclude.m4
On 22.06.2013 15:26, Eric Covener wrote: On Sun, Jun 6, 2010 at 6:05 PM, rj...@apache.org wrote: Author: rjung Date: Sun Jun 6 22:05:17 2010 New Revision: 952007 URL: http://svn.apache.org/viewvc?rev=952007view=rev Log: make shared moduled and module set most the default. Static building can be achieved with --enable-mods-static or as previously using --enable-MODULE=static. The existing --enable-mods-shared still works for compatibility with existing build scripts. I just stumbled on this 2.4 difference. If someone passes --enable-mods-shared=foo bar baz do you think module_selection should be reset? Currently you get the union of most and what you selected. Configure docs page currently says: Choosing modules to compile Most modules are compiled by default and have to be disabled explicitly or by using the keywords few or none (see --enable-modules, --enable-mods-shared and --enable-mods-static below for further explanation) to be removed. So I'd say if one uses a plain --enable-MODULE=shared then the list should not get reset. That's what I would find logical behavior. Further down that page it says: --enable-mods-shared=MODULE-LIST Defines a list of modules to be enabled and build as dynamic shared modules. This mean, these module have to be loaded dynamically by using the LoadModule directive. MODULE-LIST is a space separated list of modulenames enclosed by quotation marks. The module names are given without the preceding mod_. For example: --enable-mods-shared='headers rewrite dav' Additionally you can use the special keywords reallyall, all, most, few and none. And here I would say if you only give a list of modules, then the list should be reset, ie. most should no longer be active. Now what would we expect if you start mixing most, few etc. and module sets? I guest it would be best to only allow one occurrence of --enable-mods-shared, hopefully that's already true. The same docs page has a very outdated Caveat: --enable-mods-shared=all does not actually build all modules. To build all modules then, one might use: ./configure \ --with-ldap \ --enable-mods-shared=all ssl ldap cache proxy authn_alias file_cache authnz_ldap charset_lite dav_lock cache_disk I hope the following statement is correct for 2.4: module set all contains all modules except for experimental and debugging modules. Module set reallyall also includes experimental and debugging modules. That both wont build modules which have their build dependencies not fulfilled (can't be build) should be obvious. Regards, Rainer
