On Sun, Jun 06, 2010 at 08:53:03PM +0200, Stefan Fritsch wrote:
On Sunday 06 June 2010, Brian Pane wrote:
As long as the documentation explained to users that they need to
have enough memory to accommodate MaxClient *
MaxOutputBufferedPerRequest (where the latter is a hypothetical
name
On Wed, Jun 16, 2010 at 12:05:21PM +0200, Graham Leggett wrote:
On 16 Jun 2010, at 10:45 AM, Joe Orton wrote:
There is already mod_buffer in trunk. From reading the docs, it
should
be suitable for this purpose. Or is it missing some functionality?
You can get many of the benefits of using
On Wed, Jun 16, 2010 at 08:16:11PM +0200, Rainer Jung wrote:
On 07.06.2010 23:16, jor...@apache.org wrote:
--- httpd/test/framework/trunk/t/apache/pr17629.t (original)
+++ httpd/test/framework/trunk/t/apache/pr17629.t Mon Jun 7 21:16:50 2010
@@ -5,7 +5,7 @@ use Apache::Test;
use
On Thu, Jun 10, 2010 at 07:28:55PM -0500, William Rowe wrote:
Have not checked specifically, the problem I observed was ejecting other
unexpired elts as other records were repeatedly updated.
It seems the simple fix is to change the pre-store free logic,
* expire records [do this only if
On Fri, Jun 11, 2010 at 11:41:25AM +0100, Dr Stephen Henson wrote:
On 11/06/2010 07:00, Ruediger Pluem wrote:
Index: lib/Apache/TestSSLCA.pm
===
--- lib/Apache/TestSSLCA.pm (Revision 946346)
+++ lib/Apache/TestSSLCA.pm
On Wed, Jun 09, 2010 at 11:30:45AM -0500, William Rowe wrote:
Just noticed that our shmcb socache never replaces an identical node
on -store, leading to multiple entries for the same id (with different
expiries and data, obviously).
Is this deliberate? What is the distcache/memcached/dbm
On Mon, Jun 07, 2010 at 12:23:26PM -, rj...@apache.org wrote:
Author: rjung
Date: Mon Jun 7 12:23:26 2010
New Revision: 952201
URL: http://svn.apache.org/viewvc?rev=952201view=rev
Log:
Add process id and thread id (if APR has thread support)
to the error log.
...
@@ -620,6 +621,18
https://issues.apache.org/bugzilla/show_bug.cgi?id=17629
Here's an attempt at fixing the dreaded PR 17629. This is a bug in the
handling of the output filter chain at the point where an internal
redirect is applied to a subrequest. Complications:
a) a subrequest's filter chain may start at
On Tue, Jun 08, 2010 at 05:20:16PM +0200, Plüm, Rüdiger, VF-Group wrote:
Is it possible to have any non subrequest specific filters below the
ap_subreq_core_filter_handle?
It is no that the current patch does not handle this but wouldn't it be
possible
to just throw away any filter between
On Tue, Jun 08, 2010 at 02:56:46PM -0500, William Rowe wrote:
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/log.c?rev=952724r1=952723r2=952724view=diff
==
--- httpd/httpd/trunk/server/log.c (original)
On Tue, Jun 08, 2010 at 06:17:29PM +0200, Plüm, Rüdiger, VF-Group wrote:
I'd spent some time working on exactly that approach, trying to
answer that question. But surprisingly the answer is yes - the
subreq filter has ftype=AP_FTYPE_CONTENT_SET, so any filter
registered with an ftype
So since nobody has told me I'm an idiot yet, I've committed this to the
trunk for wider testing:
http://svn.apache.org/viewvc?view=revisionrevision=952828
Regards, Joe
On Wed, Jun 02, 2010 at 10:42:44PM +0200, Stefan Fritsch wrote:
The patch is at
http://people.apache.org/~sf/per-module-loglevel-v4/ ,
This looks good to me. Kudos for taking on such a task. It's kind of
hard to review the individual patches with fixes-on-fixes separated out,
or the
On Fri, Jun 04, 2010 at 01:40:42PM +0200, Plüm, Rüdiger, VF-Group wrote:
memset(l-module_levels, val, total_modules +
DYNAMIC_MODULE_LIMIT);
Hm, module_levels is int[] and memset works byte wise.
Doh. Sorry, yes, ignore me there.
Thanks very much for all the responses. There is strong consensus for
retaining support for some varieties of 0.9.8 and possibly some 0.9.7.
A new RFC, then, for trunk/2.3 and beyond:
- support and build warning-free with OpenSSL = 0.9.8
- support and build with OpenSSL = 0.9.7a, albeit with
On Wed, Jun 02, 2010 at 01:18:17PM -0500, William Rowe wrote:
On 6/2/2010 11:23 AM, Joe Orton wrote:
Thanks very much for all the responses. There is strong consensus for
retaining support for some varieties of 0.9.8 and possibly some 0.9.7.
A new RFC, then, for trunk/2.3 and beyond
On Tue, May 25, 2010 at 03:49:33AM +, Philip M. Gollucci wrote:
Is there any easy way to run this for 2.0.x ?
The test suite should run for 2.0 just the same as for 2.2, though there
may be many more test failures. Is it broken?
Regards, Joe
I'd like to drop support for versions of OpenSSL older than 1.0 in the
trunk mod_ssl. We have 200+ lines of compat macro junk and still six
different compiler warnings remain in a trunk build against 1.0.0.
pro: simplify code: remove ssl_toolkit_compat.h and all compat macro
mess which
On Mon, May 24, 2010 at 02:39:29PM +0200, Ruediger Pluem wrote:
On 24.05.2010 12:44, jor...@apache.org wrote:
+ IfVersion = 2.3.0
+ # resp{Content-Type} = /text/ should be equivalent but
+ # doesn't seem to work.
+ FilterProvider pr49328 DEFLATE true
On Wed, May 12, 2010 at 03:30:29PM -0400, Jeff Trawick wrote:
The multiple-calls-to-pool_clear solution is definitely safer.
OK, so now I reviewed that too ;) The only difference between:
apr_pool_clear(ptrans);
apr_pool_destroy(pchild);
and simply:
apr_pool_destroy(pchild);
(given
On Tue, May 18, 2010 at 09:18:23AM +0200, Stefan Fritsch wrote:
On Tue, 18 May 2010, Ruediger Pluem wrote:
So if you want to close this fd you IMHO would need to do some refcounting
and only close it if no other filebucket still references it.
The filebuckets already do refcounting.
On Mon, May 10, 2010 at 08:47:59PM -, Jeff Trawick wrote:
--- httpd/httpd/trunk/server/mpm/prefork/prefork.c (original)
+++ httpd/httpd/trunk/server/mpm/prefork/prefork.c Mon May 10 20:47:59 2010
@@ -549,12 +549,6 @@ static void child_main(int child_num_arg
conn_rec *current_conn;
On Wed, Apr 28, 2010 at 03:05:07PM +0300, Tasos Andras wrote:
Oh, by the way, what was your answer for:
There is a number of serious security problems in apache that we have
fixed, and that have been offered them back, and they refused.
@
http://marc.info/?l=openbsd-miscm=108655793112947w=2
On Fri, Mar 12, 2010 at 08:47:48PM +0100, Stefan Fritsch wrote:
I have also tried inserting the filter in pre_connection and storing
the socket as filter context, and then removing the filter in the
first invocation of reqtimeout_filter. But this did not work well
either, because
On Tue, Mar 09, 2010 at 02:43:08PM -0600, William Rowe wrote:
On 3/9/2010 11:15 AM, Jeff Trawick wrote:
On Tue, Mar 9, 2010 at 11:52 AM, wr...@apache.org wrote:
Author: wrowe
Date: Tue Mar 9 11:52:32 2010
New Revision: 113
Log:
For 2.0 patch available, note different line numbers
On Wed, Mar 03, 2010 at 10:40:34PM +, Dr Stephen Henson wrote:
Joe Orton wrote:
On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote:
Note that you don't need to abort if secure renegotiation is supported
by the client.
Is there any technical need to support client
On Tue, Mar 02, 2010 at 04:01:29AM -, William Rowe wrote:
Author: wrowe
Date: Tue Mar 2 04:01:29 2010
New Revision: 917867
URL: http://svn.apache.org/viewvc?rev=917867view=rev
Log:
Ensure each subrequest has a shallow copy of headers_in so that the
parent request headers are not
On Wed, Mar 03, 2010 at 10:12:55AM +, Mark J Cox wrote:
This seems like a borderline case, but we should assign a CVE name -
Mark, can you assign one?
It's low severity, but it probably should have got one earlier, yes. Use
CVE-2010-0434.
Thanks a lot. Joe
[+1] Release 2.2.15
Testing looks good on Fedora 12/x86_64. diff vs .14 is fine, sigs good,
CHANGES good. Thanks for RM-ing!
Minor note: a BOM has mysteriously appeared in CHANGES again :)
Regards, Joe
On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote:
If I understand the code correctly it looks like Apache is already
trapping and aborting client initiated renegotiations so this hang
situation shouldn't arise.
This is true for client-initiated reneg, I'm not sure whether
On Wed, Mar 03, 2010 at 11:21:47PM +0100, Mladen Turk wrote:
SSLInsecureRenegotiation off
echo R | openssl-0.9.8m s_client .. disconnects
echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout
Ah, right, hmm. Yes, this is exactly as Bill says, the client is
ignoring the alert and
On Mon, Mar 01, 2010 at 01:31:36AM -, Graham Leggett wrote:
--- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_io.c (original)
+++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_io.c Mon Mar 1
01:31:36 2010
@@ -465,7 +465,6 @@
apr_size_t inl = inlen;
bio_filter_in_ctx_t
On Mon, Mar 01, 2010 at 11:49:44AM +, Joe Orton wrote:
On Mon, Mar 01, 2010 at 01:31:36AM -, Graham Leggett wrote:
--- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_io.c (original)
+++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_io.c Mon Mar 1
01:31:36 2010
On Mon, Mar 01, 2010 at 02:59:18PM -0600, William Rowe wrote:
On 3/1/2010 8:49 AM, Joe Orton wrote:
+/* Abort early if the client has initiated a renegotiation. */
+if (inctx-filter_ctx-config-reneg_state == RENEG_ABORT) {
+inctx-rc = APR_ECONNABORTED;
+return
On Mon, Mar 01, 2010 at 08:44:12AM -0500, Dan Poirier wrote:
--- config.c (revision 916378)
+++ config.c (working copy)
@@ -1710,8 +1710,17 @@
strcmp(dirent.name, ..)
(apr_fnmatch(fname, dirent.name,
APR_FNM_PERIOD) == APR_SUCCESS))
On Fri, Feb 26, 2010 at 12:17:14PM +0100, Rainer Jung wrote:
Isn't 0.9.8m by default still allowing unsafe renegs? So updated
clients will be safe, but the server doesn't enforce the safetyness
(and reject unsafe client).
No, OpenSSL now only allows secure reneg by default, so this is
On Fri, Feb 26, 2010 at 12:17:14PM +0100, Rainer Jung wrote:
Joe, do you already have a candidate, or should I suggest a backport
patch myself?
Here's the patch:
http://people.apache.org/~jorton/ms_reneg22_v1.diff
I've excluded the docs from that since they don't require RTC, but
obviously
On Fri, Feb 26, 2010 at 12:55:38PM -0500, Jeff Trawick wrote:
On Tue, Feb 9, 2010 at 7:46 AM, jor...@apache.org wrote:
--- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Tue Feb 9 12:46:17
2010
@@ -637,7 +637,8 @@
On Wed, Feb 17, 2010 at 09:12:03AM -0500, Jeff Trawick wrote:
a. get the server to steady state
...
b. see what causes the heap to expand (brk/sbrk)
This is what I do too, FWIW. It's primitive but usually effective.
Regards, Joe
On Tue, Feb 09, 2010 at 03:43:18AM -, William Rowe wrote:
Author: wrowe
Date: Tue Feb 9 03:43:18 2010
New Revision: 907917
URL: http://svn.apache.org/viewvc?rev=907917view=rev
Log:
distcache already demonstrates sub-second resolutions, but much more
importantly, let us not introduce
On Wed, Jan 27, 2010 at 10:41:02PM +, Dr Stephen Henson wrote:
FYI the initial documentation is here:
http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION
there are currently only two flags to set in an SSL/SSL_CTX structure. Though
servers might want to make
On Wed, Feb 03, 2010 at 11:51:16AM -0500, Dan Poirier wrote:
How about logging a dire warning during startup if insecure
renegotiation has been enabled?
Hmmm, I'm not sure. If the user has configured this it seems slightly
patronising to then berate them for doing so. Also, why log in the
On Wed, Feb 03, 2010 at 12:44:45PM -0500, Eric Covener wrote:
On Wed, Feb 3, 2010 at 12:09 PM, Joe Orton jor...@redhat.com wrote:
I considered logging a warning for each client which renegotiates
insecurely (whether due to lack of support on client or server), but,
that's likely
On Wed, Feb 03, 2010 at 03:33:23PM -0600, William Rowe wrote:
On 2/3/2010 3:18 PM, Joe Orton wrote:
On Wed, Feb 03, 2010 at 12:44:45PM -0500, Eric Covener wrote:
On Wed, Feb 3, 2010 at 12:09 PM, Joe Orton jor...@redhat.com wrote:
I considered logging a warning for each client which
On Sun, Dec 13, 2009 at 06:59:37PM +0100, Ruediger Pluem wrote:
On 26.11.2009 22:06, Ruediger Pluem wrote:
On 11/19/2009 04:58 PM, Joe Orton wrote:
Yes, I agree, this seems very sensible, I can't see any problem with
this.
I would prefer to do it in a slightly more general way
On Fri, Dec 04, 2009 at 07:48:02PM -0600, William Rowe wrote:
Joe Orton wrote:
1) the httpd project cannot force the APR project to commit to API
stability by distributing a snapshot of the APR 1.4 branch. Why on
earth would that be the case? The only time the APR project commits
On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
Paul Querna wrote:
Vote Results:
+1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
+1: Gregg Smith
+/-0: Rainer Jung
-1: William A. Rowe, Jr.
Vote passes.
I'm sorry. I explicitly
On Wed, Nov 25, 2009 at 02:43:42PM -0800, Paul Querna wrote:
Test tarballs for Apache httpd 2.3.4-alpha are available at:
http://httpd.apache.org/dev/dist/
Your votes please;
+/- 1
[+1] Release httpd-2.3.4 as Alpha
Sorry I'm late - thanks for RMing! +1 here for Alpha.
* passes
On Wed, Nov 18, 2009 at 09:54:34AM -0500, Jeff Trawick wrote:
enable session cache by default?
Yes! I've been moving towards this goal - creating a default socache
provider is simple now.
Regards, Joe
On Wed, Nov 18, 2009 at 01:18:55PM -0500, Jeff Trawick wrote:
A. simplistic goal: Just make it simple for modules with no special
issues or love of complexity. Provide these directives to set global
defaults for modules that have been modified to query them:
use MutexMethod and MutexFileDir
On Tue, Nov 17, 2009 at 06:12:41PM +0100, Hartmut Keil wrote:
The client must stop and wait for the response in any case, otherwise the
response of a subsequent request will get lost, if the server is not
configured
for keep-alive, or the response for the first request causes the server to
On Thu, Nov 19, 2009 at 04:05:34PM +0100, Hartmut Keil wrote:
With the proposed change, we prevent request splitting attacks based
on the TSL renegotiation flaw. From my point of view without
drawbacks, since 'pipelining' clients must handle the closing of a
connection after a complete
On Thu, Nov 19, 2009 at 06:47:56AM -0500, Jeff Trawick wrote:
I envisioned the conf (perhaps a vendor conf) declaring something like
MutexDir logs
or
MutexDir /var/apache2/2.2/locks
The admin can then adjust the mutex methods as necessary and not worry
about paths to locks. Or change
On Tue, Nov 17, 2009 at 10:06:32AM +0100, Plüm, Rüdiger, VF-Group wrote:
I now see the following warning:
ssl_engine_kernel.c: In function `ssl_callback_Info':
ssl_engine_kernel.c:1943: warning: passing arg 1 of `SSL_state' discards
qualifiers from pointer target type
r881222 should fix it.
On Fri, Nov 06, 2009 at 02:00:47AM +, Dirk-Willem van Gulik wrote:
What we really need is 1) a pub/priv key pair of such a cert* (or use
attached CSR) of some random domain (ideally expired and with a totally
bogus CN valye so we can post the private key publicly) and 2) obviously
a
On Mon, Nov 16, 2009 at 08:21:20PM +0100, Jean-Marc Desperrier wrote:
Ok, so in fact I have one apache instance available locally with a
problem of this kind. It's configured to not require client
authentication by defaut, but to require it on the /authentication url
So what happens truly
On Mon, Nov 16, 2009 at 09:59:12PM +0100, Hartmut Keil wrote:
With the change described in
https://issues.apache.org/bugzilla/show_bug.cgi?id=48204
the buffer used in ssl_io_input_read(..) will be reset, and so the second
request of
the MITM will be dropped.
The first request will be
On Mon, Nov 09, 2009 at 07:06:16PM +0100, Kaspar Brand wrote:
Dr Stephen Henson wrote:
Yes that looks better. There is an alternative technique if it is easier to
find
a base SSL_CTX, you can retrieve the auto generated keys using
SSL_CTX_get_tlsext_ticket_keys() and then copy to the new
On Tue, Nov 10, 2009 at 03:19:39PM +0100, Jean-Marc Desperrier wrote:
Joe Orton wrote:
On Fri, Nov 06, 2009 at 12:00:06AM +, Joe Orton wrote:
On Thu, Nov 05, 2009 at 09:31:00PM +, Joe Orton wrote:
* we can detect in mod_ssl when the client is renegotiating by using
On Fri, Nov 06, 2009 at 12:00:06AM +, Joe Orton wrote:
On Thu, Nov 05, 2009 at 09:31:00PM +, Joe Orton wrote:
* we can detect in mod_ssl when the client is renegotiating by using the
callback installed using SSL_CTX_set_info_callback(), in conjunction
with suitable flags
On Thu, Nov 05, 2009 at 09:38:23PM +0100, Ruediger Pluem wrote:
If server triggered renegotiation will not work at all, people will just
ignore the
update or remove it from 0.9.8l in their self patched versions.
So overall I guess we would be safer with an approach that
1. Turns off
On Thu, Nov 05, 2009 at 09:31:00PM +, Joe Orton wrote:
* we can detect in mod_ssl when the client is renegotiating by using the
callback installed using SSL_CTX_set_info_callback(), in conjunction
with suitable flags in the SSLConnRec to detect the cases where this is
either a server
On Fri, Nov 06, 2009 at 12:00:06AM +, Joe Orton wrote:
On Thu, Nov 05, 2009 at 09:31:00PM +, Joe Orton wrote:
* we can detect in mod_ssl when the client is renegotiating by using the
callback installed using SSL_CTX_set_info_callback(), in conjunction
with suitable flags
On Mon, Oct 26, 2009 at 12:44:17AM +0100, Ruediger Pluem wrote:
On 10/25/2009 06:21 PM, jor...@apache.org wrote:
Author: jorton
Date: Sun Oct 25 17:21:10 2009
New Revision: 829619
URL: http://svn.apache.org/viewvc?rev=829619view=rev
Log:
Add support for OCSP stapling:
...
Will
On Tue, Oct 27, 2009 at 03:14:55AM +0100, Guenter Knauf wrote:
Hi Joe, Steve,
I have some probs with getting this compiled;
first its inclear for me from where HAVE_OCSP should get defined in
ssl_toolkit.compat.h - for me it seems its not defined in line 42, thus
#include openssl/ocsp.h
in
On Fri, Oct 23, 2009 at 06:08:52PM +0200, Kaspar Brand wrote:
Kamesh Jayachandran wrote:
Find the tcpdump while this failure occurs at
http://www.livecipher.com/tlsext_dump/tlsext.dmp
It seems that you used a URI with an IP address (https://10.2.1.97/...),
is that correct? This actually
On Wed, Sep 16, 2009 at 01:45:30PM +0100, Joe Orton wrote:
On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote:
I may have missed something here but the OCSP stapling code doesn't appear
to be
in trunk. The patch in:
https://issues.apache.org/bugzilla/show_bug.cgi?id
On Thu, Oct 22, 2009 at 12:49:10PM +0530, Kamesh Jayachandran wrote:
I tried your patch. It does *not* fix the issue.
One difference it makes is , triggers failure early at 20/30 files(PUT
requests) instead of 20k files earlier.
Can you get a packet dump/trace from the client side? Is there
On Sun, Oct 18, 2009 at 09:50:25PM +0200, Stefan Fritsch wrote:
On Thursday 15 October 2009, Dick Davies wrote:
In any event, does it made sense to use something other than the
inode as the key into the lockDB - the URI for example?
Is the performance improvement of inode keyed locking so
On Fri, Oct 16, 2009 at 03:32:04PM -0400, Jeff Trawick wrote:
..
--- Apache-Test/lib/Apache/TestConfigParse.pm (revision 822728)
+++ Apache-Test/lib/Apache/TestConfigParse.pm (working copy)
@@ -224,15 +224,15 @@
$name = $modname_alias{$name} if $modname_alias{$name};
-#
On Fri, Oct 09, 2009 at 07:56:42PM +0200, Graham Leggett wrote:
I am trying to solve the problem of limiting access to those who present
a client cert containing a specific extKeyUsage OID.
So far, the config that I have for httpd-trunk is this:
SSLRequire 1.3.6.1.5.5.7.3.4 in
On Thu, Oct 15, 2009 at 03:43:36PM +0200, Graham Leggett wrote:
Joe Orton wrote:
Are you trying to match against the contents of the (single) extKeyUsage
extension? That isn't how PeerExtList works, or at least, was written
and documented to work, AFAICT: PeerExtList will return a list
On Thu, Oct 15, 2009 at 03:27:29PM +0100, Dick Davies wrote:
[sorry for the crosspost, but not sure where this should go].
To answer my own question:
got to the bottom of it; looks to me like the
lock DB is a hash of
inode - locktoken
Steps to reproduce:
* PUT file
* LOCK file
*
On Mon, Oct 12, 2009 at 05:14:33PM -0400, Brian J. France wrote:
mod_dav_acl would use the filename to validate the acls. Like I said, I
don't know if get_pathname is needed or we should just use r-filename
and make sure a mod_dav_fs_db module updated it.
Why does mod_dav_acl care about
On Fri, Oct 09, 2009 at 09:41:32PM -, Graham Leggett wrote:
--- httpd/httpd/trunk/modules/dav/main/mod_dav.h (original)
+++ httpd/httpd/trunk/modules/dav/main/mod_dav.h Fri Oct 9 21:41:31 2009
@@ -1940,6 +1940,12 @@
** then this field may be used. In most cases, it will just be NULL.
On Sat, Oct 10, 2009 at 10:04:57AM +0200, Ruediger Pluem wrote:
On 10/09/2009 11:41 PM, minf...@apache.org wrote:
==
--- httpd/httpd/trunk/modules/dav/fs/repos.c (original)
+++
On Mon, Oct 12, 2009 at 04:23:59PM -0400, Brian J. France wrote:
On Oct 12, 2009, at 3:57 AM, Joe Orton wrote:
On Fri, Oct 09, 2009 at 09:41:32PM -, Graham Leggett wrote:
--- httpd/httpd/trunk/modules/dav/main/mod_dav.h (original)
+++ httpd/httpd/trunk/modules/dav/main/mod_dav.h Fri Oct 9
On Mon, Oct 12, 2009 at 04:17:00PM -0400, Brian J. France wrote:
On Oct 12, 2009, at 3:58 AM, Joe Orton wrote:
On Sat, Oct 10, 2009 at 10:04:57AM +0200, Ruediger Pluem wrote:
This creates the following warning:
repos.c:1827: warning: initialization from incompatible pointer type
Plus
On Wed, Sep 16, 2009 at 10:09:23AM +0300, Jari Urpalainen wrote:
I'll assume that you don't need here the content which is included
within mod_dav_acl package at sf.net ? Otherwise you are certainly free
to use it anyways you like. Patch contains mostly some hooks to
mod_dav, but since i'm not
On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote:
I may have missed something here but the OCSP stapling code doesn't appear to
be
in trunk. The patch in:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43822
doesn't apply cleanly any more, though the changes needed
On Sat, Sep 12, 2009 at 10:43:29PM +0200, Stefan Fritsch wrote:
On Fri, 11 Sep 2009, Joe Orton wrote:
+char *p = ap_strchr(reply, '('), *ep, *term;
+long port;
+
+/* Reply syntax per RFC 2428: 229 blah blah (|||port|) where '|'
+ * can be any character in ASCII from 33-126
On Mon, Sep 14, 2009 at 09:04:08PM +0200, Ruediger Pluem wrote:
On 09/14/2009 04:16 PM, jor...@apache.org wrote:
+/* Reply syntax per RFC 2428: 229 blah blah (|||port|) where '|'
+ * can be any character in ASCII from 33-126, obscurely. Verify
+ * the syntax. */
+p =
On Mon, Sep 14, 2009 at 10:11:24AM -0400, Brian J. France wrote:
I would like to get some form of mod_dav_acl[1] added to httpd. My end
goal with all of this is to get a mod_caldav and mod_cardav accepted down
the line or at least be able to build the module with out hacking the
core httpd
On Thu, Sep 10, 2009 at 07:02:01PM +0200, Stefan Fritsch wrote:
in case you haven't noticed yet, some new mod_proxy_ftp issues have
been reported:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3094
The ap_proxy_ftp_handler function in modules/proxy/proxy_ftp.c in the
On Fri, Sep 11, 2009 at 10:51:11PM +0200, Ruediger Pluem wrote:
On 09/11/2009 04:52 PM, Joe Orton wrote:
On Thu, Sep 10, 2009 at 07:02:01PM +0200, Stefan Fritsch wrote:
The (untested) patch below should fix CVE-2009-3094. For CVE-2009-3095
there is only little information. But looking
On Wed, Sep 09, 2009 at 10:22:28PM +0200, Peter Sylvester wrote:
The patch for 724717 moves some logic from ssl_engine_kernel into
ssl__engine_vars and simplifies the code (and enhances it btw).
Can this code be backported to the 2.2.x version
Have you done any testing on that? I hadn't done
On Sun, Aug 23, 2009 at 08:30:47PM -, n...@apache.org wrote:
Author: niq
Date: Sun Aug 23 20:30:47 2009
New Revision: 807015
URL: http://svn.apache.org/viewvc?rev=807015view=rev
Log:
Preserve port over internal redirection
PR#35999
A four-year-old buglet!
Please, please, please, can
CC'ing d...@.
On Tue, Aug 18, 2009 at 09:26:24PM +0100, Alex Stapleton wrote:
First some background. We use Apache HTTPD 2.0 over a high-latency,
high packet loss GPRS WAN. The cost per byte is tangible. We use SSL.
We also use Transfer-Encoding: chunked sometimes. This is a machine
On Tue, Jul 28, 2009 at 07:35:25PM +0200, Stefan Fritsch wrote:
Hi,
I have backported r791454 to 2.2.3 in Debian 4.0 and have received a
report [1] about segfaults with mod_deflate and mod_php (5.2.0). As
far as I understand it, the reason is that mod_php uses ap_rwrite
which creates
On Mon, Aug 03, 2009 at 01:09:35PM +0200, Ruediger Pluem wrote:
On 08/03/2009 12:52 PM, Joe Orton wrote:
On Tue, Jul 28, 2009 at 07:35:25PM +0200, Stefan Fritsch wrote:
I have backported r791454 to 2.2.3 in Debian 4.0 and have received a
report [1] about segfaults with mod_deflate
On Tue, Jul 14, 2009 at 05:47:16PM +0200, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: William A. Rowe, Jr.
Sent: Montag, 13. Juli 2009 23:58
To: dev@httpd.apache.org
Subject: Re: mod_deflate DoS using HEAD
Nick Kew wrote:
Eric Covener wrote:
On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger, VF-Group wrote:
I'm confused. Why do this check so late, and why does r-bytes_sent
matter? Why does it screw up the protocol if the DEFLATE
All depends on the first brigade that passes mod_deflate. If this brigade
contains the
On Thu, Jul 09, 2009 at 09:48:29AM -0400, Dan Poirier wrote:
So if the content-length was parsed correctly, but the vulnerability
related to additional data wasn't fixed, this test would still pass?
(Since then we're not sending any more data than expected?)
That is phrased almost as if there
force a
+ proxy process to consume CPU time indefinitely. [Nick Kew, Joe Orton]
I thought in this instance, the original reporter's diagnostic
work contributed more to the patch than we did. I think he
should be credited in the changelog here.
Lots of people help out with diagnosis
modules, by forcing the server to consume CPU time in compressing a
large file after a client disconnects. [Joe Orton, Ruediger Pluem]
One of the patches was for
https://issues.apache.org/bugzilla/show_bug.cgi?id=39605, although that has
a different symptom. (See comment in
http
On Sun, Jun 28, 2009 at 08:20:20PM +0200, Stefan Fritsch wrote:
we have received a bug report [1] that a DoS is possible with
mod_deflate since it does not stop to compress large files even after
the network connection has been closed. This allows to use large
amounts of CPU if there is a
On Wed, Jul 01, 2009 at 03:01:55PM -, n...@apache.org wrote:
Author: niq
Date: Wed Jul 1 15:01:55 2009
New Revision: 790205
URL: http://svn.apache.org/viewvc?rev=790205view=rev
Log:
mod_noloris just moved from discussion to attracting its first patch
on d...@. That means it wants to
On Fri, Jun 26, 2009 at 03:55:27PM +0200, Natanael Mignon - michael-wessel.de
wrote:
I am currently working on - dirty, please have mercy - customizations
of mod_ssl and especially OCSP-handling for a specific project (on
basis of Apache 2.3 code). As I am neither a seasoned C-coder nor
On Thu, Jul 02, 2009 at 01:37:22PM +0100, Nick Kew wrote:
Joe Orton wrote:
1) A *linear-time* search on a shm segment, using strstr.
2) ... for each new connection.
With the expectation that the shm segment normally has strlen
of zero, and even under attack is just a few bytes.
As far
On Mon, Jun 22, 2009 at 09:48:46PM -0700, Paul Querna wrote:
On Sun, Jun 21, 2009 at 4:10 AM, Andreas Krennmaira...@synflood.at wrote:
Hello everyone,
.
The basic principle is that the timeout for new connections is adjusted
according to the current load on the Apache instance: a load
601 - 700 of 1530 matches
Mail list logo
