Has anyone checked this out yet?
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0492
It was reported in cnet news a month or two ago, and my SOX security
guys at work have been bugging me about it... I need to tell them
either it's a false alarm or it will be fixed soon.
Any current
or it will be fixed soon.
Any current status on it?
Fixed in 1.3.31-dev and in 1.3.32 which will be tagged this week
and likely released early next week.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
According to David:
It was reported in cnet news a month or two ago, and my SOX security
guys at work have been bugging me about it... I need to tell them
either it's a false alarm or it will be fixed soon.
A patch is available since June at
On Wed, 9 Jun 2004, Jim Jagielski wrote:
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
I guess what we are agreeing on here is that the logic that sets
keepalive
to 0 is faulty and that is probably where the real fix lies.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
I had sent private Email to your @apache.org address
(since that's the one you use to provide HTTPD related
patches).
On Jun 8, 2004, at 5:10 PM, Rasmus Lerdorf wrote:
Uh, I never received anything on this. Did you actually send me
something? I'll have a look at addressing this issue. Releasing
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should determine this prior to the ap_die
and set conn-keepalive to 1. Or am I missing something with respect to
what
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should determine this prior to the ap_die
and set
On Wed, 9 Jun 2004, Joe Orton wrote:
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should
On Wed, Jun 09, 2004 at 11:04:23AM -0700, Rasmus Lerdorf wrote:
On Wed, 9 Jun 2004, Joe Orton wrote:
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have
On Wed, 9 Jun 2004, Joe Orton wrote:
When ap_die() is called, ap_set_keepalive() has not been called, and
r-connection-keepalive is set to 0, as it was initialized so.
The last thing ap_die does is call ap_send_error_response, which calls
ap_send_http_header, which calls ap_set_keepalive,
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
I guess what we are agreeing on here is that the logic that sets
keepalive
to 0 is faulty and that is probably where the real fix lies.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
even after we know the connection will be
William A. Rowe, Jr. wrote:
At 07:09 AM 5/28/2004, Jim Jagielski wrote:
I've backed out that patch and asked Rasmus to send a replacemnet
which addresses his specific problem but does not cause
the below behavior.
I'm tempted to release 1.3.32...
Collect another week or few of data on
Jeff Trawick wrote:
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
Backing out the patch also fixes a DAV regression. See
http://issues.apache.org/bugzilla/show_bug.cgi?id=29237
See also
On Fri, May 28, 2004 at 06:14:30AM -0400, Jeff Trawick wrote:
Jeff Trawick wrote:
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
Backing out the patch also fixes a DAV regression. See
Hmm.. this was a patch suggested by Rasmus, iirc.
Jeff Trawick wrote:
Jeff Trawick wrote:
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
Backing out the patch also fixes a DAV regression. See
I've backed out that patch and asked Rasmus to send a replacemnet
which addresses his specific problem but does not cause
the below behavior.
I'm tempted to release 1.3.32...
Jeff Trawick wrote:
This patch did it:
At 07:09 AM 5/28/2004, Jim Jagielski wrote:
I've backed out that patch and asked Rasmus to send a replacemnet
which addresses his specific problem but does not cause
the below behavior.
I'm tempted to release 1.3.32...
Collect another week or few of data on other problems first, perhaps?
Once
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
See also
http://issues.apache.org/bugzilla/show_bug.cgi?id=29257
http://www.rtr.com/fp2002disc/_disc2/0a71.htm
I'd like to announce and release the 11th.
Are we still on track for this? Reports seem to have been good ...
Kean
cross-posting to test-dev@, which is probably where we ought to discuss the
gory details...
Failed Test Stat Wstat Total Fail Failed List of Failed
at this point the test part of the perl-framework is
'.
/tmp/ap/bin/httpd -d /home/sctemme/asf/perl-framework/t -f
/home/sctemme/asf/perl-framework/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
using Apache/1.3.31
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 3 secs)
server eartha:8529 started
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that
for `all'.
/tmp/ap/bin/httpd -d /home/sctemme/asf/perl-framework/t -f
/home/sctemme/asf/perl-framework/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
using Apache/1.3.31
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 3 secs)
server eartha:8529
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that
Looking for negative (do-not-release) feedback for the
1.3.31 RC tarballs...
No negative feedback. +1 so far on NetWare
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Monday, May 10, 2004 11:55:50 AM
Looking for negative (do-not-release) feedback for the
1.3.31 RC
Jim Jagielski wrote:
Via:
http://httpd.apache.org/dev/dist/
Looks good on SCO OpenServer 5.0.7 and UnixWare 7.1.3.
Kean
Looks good on gentoo as well.
chuck
On Sunday 09 May 2004 17:02, Kean Johnston wrote:
Jim Jagielski wrote:
Via:
http://httpd.apache.org/dev/dist/
Looks good on SCO OpenServer 5.0.7 and UnixWare 7.1.3.
Kean
cross-posting to test-dev@, which is probably where we ought to discuss the
gory details...
Failed Test Stat Wstat Total Fail Failed List of Failed
at this point the test part of the perl-framework is
Aaron Bannert wrote:
I believe that a strict QA process actually hurts the quality
of OSS projects like Apache. We have a gigantic pool of
talented users who would love to give us a hand by testing
our latest and greatest in every contorted way imaginable.
But we're holding out on them.
I ran the perl-framework against the tarball on three platforms:
On Darwin MonaLisa 7.3.0 Darwin Kernel Version 7.3.0: Fri Mar 5
14:22:55 PST 2004; root:xnu/xnu-517.3.15.obj~4/RELEASE_PPC Power
Macintosh powerpc
Failed Test Stat Wstat Total Fail Failed List of Failed
On May 8, 2004, at 4:05 AM, Jim Jagielski wrote:
I don't consider us a closely held ivory-tower QA and I would
say that if anyone knows of a talented pool of users would would
like to test RCs, then we should have a mechanism to use them.
That was the intent for the current/stable-testers list,
Aaron Bannert wrote:
I still don't see
why any stage in the release process should be closed, though.
We don't make any guarantees about any of our code at any time,
Well, yes, you're right, we don't make any guarantees, but
certainly our intent and desire is that we produce the best
Jim Jagielski wrote (on 4/28/2004):
The TR of 1.3.31 will be done within the next day or 2 with a
formal release likely early next week.
Any update on plans?
--
Jess Holle
Via:
http://httpd.apache.org/dev/dist/
I'd like to announce and release the 11th.
The URL has been posted on slashdot :-(
Joshua.
* Joshua Slive [EMAIL PROTECTED] wrote:
The URL has been posted on slashdot :-(
:-( I'd say, let's move it away. It's not released yet. period.
nd
--
print Just Another Perl Hacker;
# André Malo, http://pub.perlig.de/ #
* Joshua Slive [EMAIL PROTECTED]
|__ Fri, May 07, 2004 at 03:14:08PM -0400:
The URL has been posted on slashdot :-(
Oh no. It's not official yet. :-/
--
Chip Cuccio| [EMAIL PROTECTED]
NORLUG VP and Sysadmin | http://norlug.org/~chipster/
Northfield Linux Users'
On May 7, 2004, at 8:15 AM, Jim Jagielski wrote:
Via:
http://httpd.apache.org/dev/dist/
I'd like to announce and release the 11th.
Except Slashdot beat you to the punch: http://apache.slashdot.org/.
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A
I have made the tarballs unavailable from the below URL. People
should contact me directly to obtain the correct URL...
Sander Temme wrote:
--Apple-Mail-1-423850141
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
On May 7, 2004,
Jim Jagielski wrote:
I have made the tarballs unavailable from the below URL. People
should contact me directly to obtain the correct URL...
I'd like to give it a testing shoot for the cygwin platform on recent
cygwin 1.5.x versions. Can you drop me an URL for it Jim please?
Stipe
Why is it bad if people download the RC version and
test it? Frankly, I really don't mind if slashdot or anyone
else broadcasts that we have an RC tarball available.
If anything it's a good thing. We don't make any guarantees
about our code anyway, so whether or not we call it a GA
release is just
The trouble is that we need to perform *some* sort of quality
control out there... The option is as soon as we have a tarball
out, it's immediately released, in which case why even bother
with a test or RC candidate. We need to, IMO, impose some
sort of order and process on how we release s/w, and
* Aaron Bannert [EMAIL PROTECTED] wrote:
Why is it bad if people download the RC version and
test it?
Frankly, I really don't mind if slashdot or anyone
else broadcasts that we have an RC tarball available.
Our traffic fee does anyway. RC stuff in /dev/dist/ is not mirrored.
nd
--
On Fri, 7 May 2004, Aaron Bannert wrote:
Why is it bad if people download the RC version and
test it? Frankly, I really don't mind if slashdot or anyone
else broadcasts that we have an RC tarball available.
The problem was that they called it a release, not an RC. I added the
header.html to
I believe that a strict QA process actually hurts the quality
of OSS projects like Apache. We have a gigantic pool of
talented users who would love to give us a hand by testing
our latest and greatest in every contorted way imaginable.
But we're holding out on them. We're saying that we know
FWIW, we're currently only using half of our allocated bandwidth.
If RC distributions become a bandwidth problem, we can think
about mirroring then (wouldn't that be a great problem to have
though?)
-aaron
On May 7, 2004, at 7:05 PM, André Malo wrote:
* Aaron Bannert [EMAIL PROTECTED] wrote:
Aaron Bannert wrote:
I believe that a strict QA process actually hurts the quality
of OSS projects like Apache. We have a gigantic pool of
talented users who would love to give us a hand by testing
I agree, but there is also a protocol to follow. If a user
is interested in testing, they should
On May 7, 2004, at 7:26 PM, Aaron Bannert wrote:
But we're holding out on them. We're saying that we know
better than they do. I don't think we do. Sure, we should be
In a way, we're holding out on them. However, I believe that a couple
of days time to sanity check an RC is IMHO not a bad thing.
Hi,
Last week it was mentioned that the 1.3.31 release process would start
on Monday. I've seen no mail indicating that has started. Is there
anything holding 1.3.31 up at this point?
Also, if RSE is reading this list, whats the lead time between 1.3.31
being tagged or released and mod_ssl
The TR of 1.3.31 will be done within the next day or 2 with a
formal release likely early next week.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little
I plan to TR 1.3.31 most likely tomorrow... speak now
or forever hold your peace.
Jim Jagielski wrote:
I plan to TR 1.3.31 most likely tomorrow... speak now
or forever hold your peace.
I don't think the mod_digest.html stuff I sent was integrated, even though
it seemed people were happy with the wording. but I didn't want to just
commit it until the RM officially said so
On Apr 26, 2004, at 1:42 PM, Geoffrey Young wrote:
I don't think the mod_digest.html stuff I sent was integrated, even
though
it seemed people were happy with the wording. but I didn't want to
just
commit it until the RM officially said so :) not that these docs are
all
that critical of an
Jim Jagielski wrote:
My schedule for 1.3.31 is a tag and roll on Monday/Tuesday
Does that mean 1.3.30 was a no-go? If so I must have missed the mail
about it.
Kean
My schedule for 1.3.31 is a tag and roll on Monday/Tuesday
with a release on Friday (I will be traveling Tuesday
and Thursday and in Seattle on Wednesday)... It's my belief
that the nonce issue is settled with the code currently in HEAD,
but would approciate a few more eyes
56 matches
Mail list logo
