[STATUS] (httpd-trunk) Wed Dec 19 23:50:38 2007
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2007-12-03 15:06:37 -0500 (Mon, 03 Dec 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on "TODO" or "XXX" in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the "PatchAvailable" bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
After testing, you can append a comment saying "Reviewed and tested".
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
"gracefully" self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
"hot spare").
See: Message-ID: <[EMAIL PROTECTED]>
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for *2.4*?
wrowe: Replies "yes"
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr->main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see "MUST" v.s. "SHOULD" v.s. "MAY"
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at least the pre-config
hook. The first time we call the hooks,
[STATUS] (httpd-2.2) Wed Dec 19 23:47:04 2007
APACHE 2.2 STATUS: -*-text-*-
Last modified at [$Date: 2007-12-15 03:42:11 -0500 (Sat, 15 Dec 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.2.7 : In development
2.2.6 : Released September 7, 2007.
2.2.5 : Tagged August 10, 2007, not released.
2.2.4 : Released on January 9, 2007 as GA.
2.2.3 : Released on July 28, 2006 as GA.
2.2.2 : Released on May 1, 2006 as GA.
2.2.1 : Tagged on April 1, 2006, not released.
2.2.0 : Released on December 1, 2005 as GA.
2.1.10 : Tagged on November 19, 2005, not released.
2.1.9 : Released on November 5, 2005 as beta.
2.1.8 : Released on October 1, 2005 as beta.
2.1.7 : Released on September 12, 2005 as beta.
2.1.6 : Released on June 27, 2005 as alpha.
2.1.5 : Tagged on June 17, 2005.
2.1.4 : not released.
2.1.3 : Released on February 22, 2005 as alpha.
2.1.2 : Released on December 8, 2004 as alpha.
2.1.1 : Released on November 19, 2004 as alpha.
2.1.0 : not released.
Contributors looking for a mission:
* Just do an egrep on "TODO" or "XXX" in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the "PatchAvailable" bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
After testing, you can append a comment saying "Reviewed and tested".
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
* Forward binary compatibility is expected of Apache 2.2.x releases, such
that no MMN major number changes will occur. Such changes can only be
made in the trunk.
* All commits to branches/2.2.x must be reflected in SVN trunk,
as well, if they apply. Logical progression is commit to trunk,
get feedback and votes on list or in STATUS, then merge into
branches/2.2.x, as applicable.
RELEASE SHOWSTOPPERS:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
[ New proposals should be added at the end of the list ]
* mod_proxy: Support variable interpolation in reverse proxy configuration
(revised proposal dealing with wrowe's concerns).
trunk:
http://svn.apache.org/viewvc?view=rev&revision=421686 (code)
http://svn.apache.org/viewvc?view=rev&revision=422178 (code)
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?r1=420990&r2=421725
(docs)
http://svn.apache.org/viewvc?view=rev&revision=589371 (code+docs)
2.2.x:
http://people.apache.org/~niq/proxy-interp.patch
rpluem says: Please add the documentation to your 2.2.x version of your
patch and a minor bump (changes to public mod_proxy.h) and
assume you are +1 to your own proposal.
niq says: I'll attend to that. As regards vote, I'm +1 on the proposal,
but -0 on including this as a new feature in 2.2.7.
Better IMHO to separate releasing it from the many bugfixes
in 2.2.7 mod_proxy. Hence +1 for 2.2.8.
PATCHES/ISSUES THAT ARE STALLED
* beos MPM: Create pmain pool and run modules' child_init hooks when
entering ap_mpm_run(), then destroy pmain when exiting ap_mpm_run().
Otherwise modules' child_init hooks appear to never be executed.
Also, destroying pmain ensures that cleanups registered in modules'
child_init hooks are performed (e.g., mod_log_config and mod_dbd).
Trunk version of patch:
http://svn.apache.org/viewvc?view=rev&revision=491922
2.2.x version of patch:
http://people.apache.org/~chrisd/patches/mod_dbd_pools_groups/mpm_child_init-beos-2.2.x.patch
+0: chrisd (abstaining; unable to test)
* PKCS#7: backport PCKS#7 patches from trunk.
+1 ben
jerenkrantz: What's the revision number to backport?
wrowe asks: ditto jerenkrantz
sctemme: svn blame suggests r424707
[STATUS] (httpd-2.0) Wed Dec 19 23:46:27 2007
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2007-12-18 22:52:08 -0500 (Tue, 18 Dec 2007) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.62 : In maintenance 2.0.61 : Released September 7, 2007. 2.0.60 : Tagged August 10, 2007, not released. 2.0.59 : released July 28, 2006 as GA. 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged April 16, 2006, not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on "TODO" or "XXX" in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the "PatchAvailable" bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=PatchAvailable After testing, you can append a comment saying "Reviewed and tested". * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: * core log.c: Work around possible solutions rejected by apr for the old implementation of apr_proc_create(), and explicitly pass the output and error channels to all log processes created. This goes all the way back to piped logs failing to run on win32. Not in or needed at trunk/, as apr 1.3.0 has the proper fix. http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch +1: wrowe rpluem says: Is this really the correct thing to do on UNIX? I am not sure if all dup2 implementation notice that both fd's are the same. Otherwise they close stdout/stderr first and du
Re: [RFC] Apache Privilege Separation for WebDAV (now against 2.2.6)
Paul Querna wrote: Michael Clark wrote: Hi Folks, I posted a note about my privilege separation patches the other day and received some good private help/feedback, and have now made the patches a considerable amount more portable and they are using apr much more extensively. The patch is now fully modular and allows mod_privsep to be compiled out (although it does add some additional hooks to the core). First off, I want to say, this is a very cool set of patches, and I would like to see it or some derivative go into trunk! Thanks. BTW - I have filled out and sent in a CLA about a week ago. I'll send an email later about issues that I think should be addressed before a possibility of this or some derivative going in (perhaps just the required vfs hooks). There are also alternative approaches I'd like to mention - such as an mpm with non-privileged accept threads that forward the accepted socket to a dynamic pool of processes running as the desired uid - they could be created on demand (out of band by a privileged parent process) for authenticated users with a minimum pool size of 0 and timed out and killed after so many seconds of inactivity. This would also get rid of BIG_SECURITY_HOLE as there would be no race with the accept thread running as root (as with the other approaches I've seen). The advantage of this approach over the privsep patches' approach would be higher performance as there would be no ping/pong for each stat/open call although I don't think it would be quite as anally secure as my approach (That said, it could still check a signed token in a separated process before forwarding the accepted socket to reduce the potential of a buffer overflow exploit in one of the unprivileged processes allowing access as another uid). To do it this way we would need the ability to forward a request mid-processing (need to see host headers, translated path and authenticate before forwarding it) - so the process that gets forwarded the accepted socket would need to receive the headers out of band (perhaps in the message sending the accepted socket). This approach would be more intrusive to the core than my current approach I think (although it wouldn't need the modules to use hooked io functions). There would still be the issue of needing the stat calls in ap_directory_walk needing to be done with higher privs before the map_to_storage and access hooks have completed (so this approach may still benefit from the privilege separated process - it is also needed for system authentication in the PAM case if using /etc/shadow). Although I think the privsep patch approach is valid given a pluggable vfs io layer which has the request_rec as context - it could then be done unobtrusively. Perhaps I should add some notes to the PrivilegeSeparation wiki page on wiki.apache.org? Due to the nature of the patch it has to change some core code to use privileged wrapper calls for file io. I can't see any way around this - I have tried to minimise the impact by adding hooks. How you stubbed out the file io seems fine for the lifetime of 2.2.x and maybe 2.4.x, but in the long run, I believe we need to support some kind of "VFS" layer, to make all IO pluggable. (open file, directory listing, etc etc). Yes. It would be nice to get some core changes that would support this patch as an external module until it is ready (and make the filesystem IO layer generally pluggable). Either way, I think having a pluggable IO layer would be a good idea. The core patch could be made more palatable by making the apr IO hook API not privsep specific. So we could change the core patch as follows: * Rename server/privsep.c -> server/vfs.c * Rename include/privsep.h -> include/vfs.h * Rename layered APR io calls from ap_privsep_ to ap_vfs_ * Change context argument on io hooks calls from privsep_token_t* to request_rec* Shall I run up a patch set like this? This could perhaps be a starting point for a vfs (I believe request_rec* would be the correct context for these vfs indirected calls?). There is only one place I need more context information than the request_rec structure - this is for the apr_stat calls in ap_directory_walk before the map_to_storage and authentication hooks have completed. I can work around this somehow (by adding the preauth stat token to the request before doing these stat calls - or perhaps hook ap_directory_walk in this vfs). Later the hook dispatcher in vfs.c (server/privsep.c) could be modified to use the context/config from request_rec to work out where to dispatch the io calls rather than the simple dispatch all calls here approach I have currently. We could then have an ap_vfs_mount API to hook which paths we want to go where. Preferably Async IO and pluggable too :-) The current approach doesn't preclude async IO as the returned file descriptors inside of the apr_file_t could have async io operations performed on them. A
Re: [VOTE] initial release of httpd-mod_ftp-0.9.0
Takashi Sato wrote: apr_cpystrn is better. Agreed. FYI - it's easier to follow if you change the subject and prefix that subject with [PATCH] when you offer these up :) Committed and thanks! Bill
Re: time for 1.3.40 and 2.2.7 ?
Guenter Knauf wrote: Hi, On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a T&R early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. any chance we can get this simple patch in to correct a type mismatch which bothers me all the time when compiling with OpenSSL 0.9.8 on NetWare? http://people.apache.org/~fuankg/diffs/ssl_scache_shmht.c.diff --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:32:58 2007 @@ -198,7 +198,7 @@ SSLModConfigRec *mc = myModConfig(s); void *vp; SSL_SESSION *sess = NULL; -UCHAR *ucpData; +MODSSL_D2I_SSL_SESSION_CONST UCHAR *ucpData; int nData; time_t expiry; time_t now; @@ -223,7 +223,7 @@ return NULL; } memcpy(&expiry, vp, sizeof(time_t)); -memcpy(ucpData, (char *)vp+sizeof(time_t), nData); +memcpy((void *)ucpData, (char *)vp+sizeof(time_t), nData); ssl_mutex_off(s); /* make sure the stuff is still not expired */ Are you certain (void *)ucpData cast is actually useful? I was pretty certain memcpy is more tolerant than that. About the rest of it, +1 Bill
Re: time for 1.3.40 and 2.2.7 ?
Hi, > On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: >> Jim Jagielski wrote: >>> Anyone opposed to us shooting for a T&R early next week? >> >> If we can get a couple of security-related-but-not-really patches >> committed to 2.0 I'd like to see that as well. I'm offering, > Sure... that would be great. Another three-for-all :) > From what I can see, both 1.3 and 2.2 are backport > free, so it's just 2.0 right now. any chance we can get this simple patch in to correct a type mismatch which bothers me all the time when compiling with OpenSSL 0.9.8 on NetWare? http://people.apache.org/~fuankg/diffs/ssl_scache_shmht.c.diff --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:32:58 2007 @@ -198,7 +198,7 @@ SSLModConfigRec *mc = myModConfig(s); void *vp; SSL_SESSION *sess = NULL; -UCHAR *ucpData; +MODSSL_D2I_SSL_SESSION_CONST UCHAR *ucpData; int nData; time_t expiry; time_t now; @@ -223,7 +223,7 @@ return NULL; } memcpy(&expiry, vp, sizeof(time_t)); -memcpy(ucpData, (char *)vp+sizeof(time_t), nData); +memcpy((void *)ucpData, (char *)vp+sizeof(time_t), nData); ssl_mutex_off(s); /* make sure the stuff is still not expired */ Guenter.
flood random substitution patch
Folks
Attached is a patch that implements a random substitution feature for
flood. You need a requesttemplate, one or more substitution variables
of the form ${varname) in the requesttemplate and a substitution file
formatted with one value per newline delimited line. There may be more
than one substitution variable per URL. The variables and files are
referred to as subst variables and subst files. Each time the URL is
sent the subst variable is replaced with one line randomly selected from
the subst file. Any part of the requesttemplate can be randomly
substituted, protocol, host, port, etc. The algorithm tries to make the
creation time of the substitution independent of the size of the subst
file. The randomness of the selection can be adversely impacted if the
sizes of the different entries in the subst file vary considerably.
In addition to the code changes implementing this there is also a sample
flood configuration file (subst-example.xml), an updated flood.dtd and a
sample subst file (subprojects) that the subst-example.xml references so
you can see the feature in action.
This code is reasonably well tested although this precise version is
somewhat new, I wanted to build against the most recent release of flood
I could get.
There are many possible enhancements to this but the current version is
a reasonable initial functionality. In particular this can only
randomize parts of the requesttemplate so headers can't be randomized,
at least at this time.
I am under the impression the patch is in the required format. Let me
know of any required changes. I hope this is found useful.
Thanks,
Guy
--
Guy Ferraiolo mailto:[EMAIL PROTECTED]
Performance Measurement & Analysis http://CNET.com
CNETtel: 1.908.541.3739
1200 Route 22 East fax: 1.908.575.7474
Bridgewater, NJ 08807 cel: 1.732.618.0250
diff --exclude-from=excludefile -urN flood-orig/config.h.in flood-patchbuild/config.h.in
--- flood-orig/config.h.in 2007-12-19 11:54:42.0 -0800
+++ flood-patchbuild/config.h.in 2007-12-19 12:32:12.0 -0800
@@ -53,6 +53,10 @@
#define XML_FARM_USEFARMER_COUNT "count"
#define XML_FARM_USEFARMER_DELAY "startdelay"
#define XML_FARM_USEFARMER_START "startcount"
+#define XML_SUBST_LIST "subst_list"
+#define XML_SUBST_ENTRY "subst_entry"
+#define XML_SUBST_VAR "subst_var"
+#define XML_SUBST_FILE "subst_file"
/* The delimiter (used above) between XML elements */
#define XML_ELEM_DELIM "."
diff --exclude-from=excludefile -urN flood-orig/examples/flood.dtd flood-patchbuild/examples/flood.dtd
--- flood-orig/examples/flood.dtd 2007-12-19 11:54:42.0 -0800
+++ flood-patchbuild/examples/flood.dtd 2007-12-19 12:32:12.0 -0800
@@ -1,5 +1,3 @@
-
-
-
-
+
@@ -46,6 +43,15 @@
+
+
diff --exclude-from=excludefile -urN flood-orig/examples/subprojects flood-patchbuild/examples/subprojects
--- flood-orig/examples/subprojects 1969-12-31 16:00:00.0 -0800
+++ flood-patchbuild/examples/subprojects 2007-12-19 12:32:12.0 -0800
@@ -0,0 +1,2 @@
+test/flood
+apreq
diff --exclude-from=excludefile -urN flood-orig/examples/subst-example.xml flood-patchbuild/examples/subst-example.xml
--- flood-orig/examples/subst-example.xml 1969-12-31 16:00:00.0 -0800
+++ flood-patchbuild/examples/subst-example.xml 2007-12-19 12:32:12.0 -0800
@@ -0,0 +1,29 @@
+
+ Test HostsA bunch of hosts we want to hithttp://httpd.apache.org/${subproject}";>http://httpd.apache.org/${subproject}
+
+Bingo
+Joe
+
+
+
+ ./subprojects
+ subproject
+
+
+
+RoundRobinProfile
+round_robin
+A Test Round Robin Configuration
+verify_200
+generic
+easy
+Test Hosts
+
+ 1
+
+Joe
+RoundRobinProfile
+23
+
+ lab split test 2
+
diff --exclude-from=excludefile -urN flood-orig/flood_round_robin.c flood-patchbuild/flood_round_robin.c
--- flood-orig/flood_round_robin.c 2007-12-19 11:54:42.0 -0800
+++ flood-patchbuild/flood_round_robin.c 2007-12-19 12:32:12.0 -0800
@@ -55,6 +55,7 @@
#include "config.h"
#include "flood_net.h"
#include "flood_round_robin.h"
+#include "flood_subst_file.h"
#include "flood_profile.h"
/* On FreeBSD, the return of regexec() is 0 or REG_NOMATCH, and REG_OK is undefined */
@@ -116,6 +117,9 @@
apr_hash_t *state;
+int subst_count;
+subst_rec_t* subst_list;
+
int current_round;
int current_url;
@@ -128,6 +132,16 @@
int size, matchsize;
regex_t re;
regmatch_t match[2];
+subst_rec_t* subst_rec_p;
+char* lookup_val;
+char subst_buf[8096];
+apr_pool_t *local_pool;
+
+if (apr_pool_create(&local_pool, NULL) != APR_SUCCESS) {
+ apr_file_printf(local_stderr, "Failed apr_pool_create!\n");
+ exit(-1);
+}
+
prev = template;
returnValue = NULL
Re: SSL client certificate extensions requirements backport
Victor Wagner wrote: On 2007.12.19 at 10:10:54 +0100, Yann wrote: The changes regarding X509V3_EXT_print() seems more problematic since the extensions values are used in string comparison (strcmp and likes), hence the "human readable version", and the I hope that saying "human readable" you mean utf-8? I'd say that "\x04\x14\x04<[EMAIL PROTECTED] 49\x00 \x04\x11\x045\x04" hardly means "human readable" Uhm - I hope you don't have such patterns in utf-8 strings. utf-8 strings will pass through comparison (although not character by character analysis) when using conventional 8 bit charset operators.
Re: SSL client certificate extensions requirements backport
On 2007.12.19 at 10:10:54 +0100, Yann wrote: > The changes regarding X509V3_EXT_print() seems more problematic since the > extensions values are used in string > comparison (strcmp and likes), hence the "human readable version", and the I hope that saying "human readable" you mean utf-8? I'd say that "\x04\x14\x04<[EMAIL PROTECTED] 49\x00 \x04\x11\x045\x04" hardly means "human readable"
Re: randomized request for apache benchmark
That's what I've got diff -urN, plain text. I'll be sending this on in a few hours. Guy On Tue, 2007-12-18 at 21:06 -0600, William A. Rowe, Jr. wrote: > Guy Ferraiolo wrote: > > I'm ready to do this tomorrow and I have asked this question before but > > so long ago I dont' recall. I have a patch which is in the standard > > format. Do I include it as text in an email or attached? > > diff -u (-U3) is the preferred format; attachments are less likely to > be munged (but as plain text please - folks read them in good old readers > such as pine ;-) > > Bill -- Guy Ferraiolo mailto:[EMAIL PROTECTED] Performance Measurement & Analysis http://CNET.com CNETtel: 1.908.541.3739 1200 Route 22 East fax: 1.908.575.7474 Bridgewater, NJ 08807 cel: 1.732.618.0250
Re: [VOTE] initial release of httpd-mod_ftp-0.9.0
I'm not good at English. If you can't catch what I say, please see the attached
patch.
This doesn't have to meet 0.9.1, but may affect performance.
modules/ftp/ftp_message.c line 53:
strncpy(outptr, time_str, outlen);
if (outlen > APR_CTIME_LEN - 1) {
*(outptr + APR_CTIME_LEN - 1) = '\0';
}
When the condition is true, outptr has been NULL-terminated by strncpy.
I thought it should be "outlen < APR_CTIME_LEN"...
But though outptr hasn't when the condition is false,
line 109:
outptr[outlen - 1] = '\0';
will NULL-terminate. So this if block is useless.
Moreover, strncpy fills '\0'. outlen is often BUFSIZ, which is very large
number.
apr_cpystrn is better.
Index: modules/ftp/ftp_message.c
===
--- modules/ftp/ftp_message.c (revision 605569)
+++ modules/ftp/ftp_message.c (working copy)
@@ -50,10 +50,7 @@
switch(*++inptr) {
case 'T':
apr_ctime(time_str, apr_time_now());
-strncpy(outptr, time_str, outlen);
-if (outlen > APR_CTIME_LEN - 1) {
-*(outptr + APR_CTIME_LEN - 1) = '\0';
-}
+apr_cpystrn(outptr, time_str, outlen);
break;
case 'C':
apr_snprintf(outptr, outlen, "%s", fc->cwd);
Re: SSL client certificate extensions requirements backport
Yann wrote: > > The changes regarding X509V3_EXT_print() seems more problematic since > the extensions values are used in string > comparison (strcmp and likes), hence the "human readable version", and > the code is actually shared with the other > expressions of the SSLRequire directive. > Well the OpenSSL extension print format is subject to change so any parsing or comparison routines could be broken by that. As well as readability changes new features are also added, for example print out of the otherName type in subject alt name is an often requested addition. There are the usual security issues of such things as embedded quotes and linefeeds being misinterpreted. > Do you mean SSLRequire treatment should specialy handle binary > comparison for certificate extensions ? > And a way to write it in the configuration file ... > A binary comparison would be difficult to handle because it would have to effectively parse the ASN1 extension encoding manually. Ideally we'd need a general purpose configurable mapping API where selective parts of a certificate can be mapped to fixed format strings. The options would vary depending on the extension type. OpenSSL would be the best place for that though. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage.
Re: [RFC] Apache Privilege Separation for WebDAV (now against 2.2.6)
Michael Clark wrote: Hi Folks, I posted a note about my privilege separation patches the other day and received some good private help/feedback, and have now made the patches a considerable amount more portable and they are using apr much more extensively. The patch is now fully modular and allows mod_privsep to be compiled out (although it does add some additional hooks to the core). First off, I want to say, this is a very cool set of patches, and I would like to see it or some derivative go into trunk! Due to the nature of the patch it has to change some core code to use privileged wrapper calls for file io. I can't see any way around this - I have tried to minimise the impact by adding hooks. How you stubbed out the file io seems fine for the lifetime of 2.2.x and maybe 2.4.x, but in the long run, I believe we need to support some kind of "VFS" layer, to make all IO pluggable. (open file, directory listing, etc etc). Preferably Async IO and pluggable too :-) Dream mode on: Dav On Mount privsep:/opt/upload # static content Mount /www/content # proxied content Mount balancer://bigcluster Anyways, if all IO was abstracted with a little VFS layer, it would mean all modules would now work with your privilege separation code, rather than just the core, mod_autoindex, and any other modules you write patches for :-)
Re: SSL client certificate extensions requirements backport
Dr Stephen Henson wrote: Yann wrote: Hi, The joined patch allows the use of client certificate extensions values (by long/short name or OID) in the mod_ssl/SSLRequire directive. This functionnality is available in the 2.2.x and trunk branches but hasn't been backported in the 2.0.61, while this can be a very usefull feature (at least we need it for our product). The backport is taken from trunk since it allows the use of long/short extensions names and it takes into account the token-name change done between 2.2.x and trunk (OID became PeerExtList): the patch allows both names to be used so that configuration files won't need changes. Any hope this could be part of the 2.0.x branch so I won't need to patch the official release ? Some comments from an OpenSSL perspective... well also as the author of the OpenSSL X509v3 extension parsing code ;-) Iterating through extensions can be done more cleanly (i.e. avoiding access to internal structures) using X509_get_ext_by_OBJ(). Similarly you should obtain the value field of an X509_EXTENSION structure using X509_EXTENSION_get_data(). The use of X509V3_EXT_print() for this purpose is problematical. It is intended to produce a human readable version of an extension. The output format is not cast in stone and as such may change from one version of OpenSSL to another to produce a more readable output. That can cause problems when an attempt is made to parse its output or even a security concern. Steve. Thanks Steve for your comments, I'll modify the patch according to your recommandations, and propose it for all the apache branches since I did not change the "trunk" use of OpenSSL. The changes regarding X509V3_EXT_print() seems more problematic since the extensions values are used in string comparison (strcmp and likes), hence the "human readable version", and the code is actually shared with the other expressions of the SSLRequire directive. Do you mean SSLRequire treatment should specialy handle binary comparison for certificate extensions ? And a way to write it in the configuration file ...
