RE: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat 3. 3.1 release

2002-01-10 Thread GOMEZ Henri

  But I'm +1 on whatever you choose. Let me know if/how
  I can help - I don't have time but I could sleep less :-)


 I concur with Costin here. Your pick is +1.
me2

Same for me, I'm ok for a release (security fixes are mandatory)
and will produce the RPM and binaries.

BTW, it will be fine to have for Tomcat 3.3 
a faster release rate than it was for 3.2, since
everybody agree that 3.3.1 is just 3.3 + bug fixes
and that added features (SSLSessionID/STM) could 
(should) be desactivated in default configuration.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat 3. 3.1 release

2002-01-09 Thread Bojan Smojver

[EMAIL PROTECTED] wrote:

 So far the changes in 3.3 tree were only bug fixes and
 what I've seen so far was pretty clear and simple -
 I think the head of 3.3 is as good or better than 3.3.0.


There were a few new features as well (at least STM pooling and 
SSLSessionID checks), but they should be either fairly safe (STM 
pooling) or turned off by default (SSLSessionID's). I agree that the 
current CVS version of 3.3 is better then the released 3.3. Many bugs 
have been fixed.


 We could also take 3.3.0, replace tomcat_utils.jar
 and label it 3.3.1  - and then in 2-3 weeks release
 3.3.2 with te head.


Why don't we just say that due to recently discovered security issues, 
the release schedule has been changed and 3.3.1 is out with the latest 
security fixes. Then 3.3.2 gets released later in an orderly fashion.


 But I'm +1 on whatever you choose. Let me know if/how
 I can help - I don't have time but I could sleep less :-)


I concur with Costin here. Your pick is +1.

Bojan


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat 3. 3.1 release

2002-01-09 Thread Larry Isaacs

Because most of the changes have been bug fixes, I'm figuring the
3.3.1 final will follow the beta a week later, maybe two.  Then,
3.3.2 can follow at its own pace. 
 
Unlike prior releases, I plan to give it a good testing as part of
developing the release plan.  I have typically left this to when
I'm trying to actually build the release when I often discover a
breakage or two that need fixing and another time consuming
retest.  (FYI: Though perhaps not terribly important, the
current HEAD of jakarta-tomcat doesn't build or run on
JDK 1.1.8, at least not on my Windows systems).
 
Since it won't be possible to fetch the patched 3.3 from
CVS using a tag or branch, I'm reluctant to give it a normal
version number.  3.3a seems like a reasonable alternative.
I'll provide full tar.gzs and zips in addition to jars to update
an existing Tomcat 3.3 installation.
 
Cheers,
Larry

-Original Message- 
From: Bojan Smojver [mailto:[EMAIL PROTECTED]] 
Sent: Wed 1/9/2002 8:26 PM 
To: Tomcat Developers List 
Cc: 
Subject: Re: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat 3. 3.1 
release



[EMAIL PROTECTED] wrote: 

 So far the changes in 3.3 tree were only bug fixes and 
 what I've seen so far was pretty clear and simple - 
 I think the head of 3.3 is as good or better than 3.3.0. 


There were a few new features as well (at least STM pooling and 
SSLSessionID checks), but they should be either fairly safe (STM 
pooling) or turned off by default (SSLSessionID's). I agree that the 
current CVS version of 3.3 is better then the released 3.3. Many bugs 
have been fixed. 


 We could also take 3.3.0, replace tomcat_utils.jar 
 and label it 3.3.1  - and then in 2-3 weeks release 
 3.3.2 with te head. 


Why don't we just say that due to recently discovered security issues, 
the release schedule has been changed and 3.3.1 is out with the latest 
security fixes. Then 3.3.2 gets released later in an orderly fashion. 


 But I'm +1 on whatever you choose. Let me know if/how 
 I can help - I don't have time but I could sleep less :-) 


I concur with Costin here. Your pick is +1. 

Bojan 


-- 
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]  
For additional commands, e-mail: mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]  




msg20050/bin0.bin
Description: application/ms-tnef

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


Re: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat 3. 3.1 release

2002-01-09 Thread Bill Barker


- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, January 09, 2002 5:26 PM
Subject: Re: Dealing with the Tomcat 3.3 aux.jsp DOS problem and a Tomcat
3. 3.1 release


 [EMAIL PROTECTED] wrote:

  So far the changes in 3.3 tree were only bug fixes and
  what I've seen so far was pretty clear and simple -
  I think the head of 3.3 is as good or better than 3.3.0.


 There were a few new features as well (at least STM pooling and
 SSLSessionID checks), but they should be either fairly safe (STM
 pooling) or turned off by default (SSLSessionID's). I agree that the
 current CVS version of 3.3 is better then the released 3.3. Many bugs
 have been fixed.
And let's not forget PureTLS support.


  We could also take 3.3.0, replace tomcat_utils.jar
  and label it 3.3.1  - and then in 2-3 weeks release
  3.3.2 with te head.


 Why don't we just say that due to recently discovered security issues,
 the release schedule has been changed and 3.3.1 is out with the latest
 security fixes. Then 3.3.2 gets released later in an orderly fashion.

This would be my preference.  There are currently 18 bugs open against 3.3
(about half of them having to do with connectors).  It would be nice to get
a chance to close them before 3.3.2.

  But I'm +1 on whatever you choose. Let me know if/how
  I can help - I don't have time but I could sleep less :-)


 I concur with Costin here. Your pick is +1.
me2

 Bojan


 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]