RE: [STATUS] Tomcat 3.2.2
Based on the number of bug reports against FileURLConnection it would appear that getting this implemented correclty probably isn't trivial. The double decode problem is caused by calling Context.getResource() for a name that came from the request URI (servlet path or path info) because these strings have already been decoded once. The spec doesn't say clearly whether the string passed to getResource() may contain URL escapes or not, but since it does return a URL and it is accessing resources within a web application, I think it is fair to assume that these strings *may* contain URL escapes. So here's what I propose: 1) The implentation of getResource() and getResourceAsStream() will remain unchanged. On JDK 1.2.2 systems this means that URL escapes won't work due to the FileURLConnection bug. On 1.3.x systems, URL escapes will work correctly. 2) If any Tomcat or Jasper code needs to call getResource() or getResourceAsStream() it will first determine that the name doesn't contain any URL escapes. If it does it will return a 404 response. We could add a new getSafeResource() method This lets servlet and JSP authors call getResource() with their own single escaped strings, but double escaped strings from the client won't be allowed. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 07, 2001 11:15 AM > To: [EMAIL PROTECTED] > Subject: RE: [STATUS] Tomcat 3.2.2 > > > On Sat, 7 Apr 2001, Marc Saegesser wrote: > > > The problem really lies in the implementation of > > sun.net.www.protocol.file.FileURLConnection. Costin's idea of > creating a > > Tomcat implementation that works the way we need it to work has > some merit. > > I'll look at what it would take implement a URLConnectionhandler. > > It seems the idea is not that good - URL is final, and changing the > file: connection seems to be a bigger hack ( i.e. will affect all VMs, > including the good ones ) than detecting a bad VM and fixing the URL. > > But on a second tought, and after a bit of reading in the Apache sources, > I think we are on the wrong track. > > I think that instead of fixing the code to deal with all possible > encoding > tricks we should just report "invalid request" if we detect double > encoding or %00 or anything suspicious ( Apache does that, we should do > the same at least for consistency ). Of course, that means some files > will not work - i.e. if you have a file named "foo%20bar%00" ( a valid > file name - "foo bar" will work ), you'll not be able to request it. But > I would rather have this as a bug than deal with security issues. > > > Costin > > > > > > > > > > -Original Message- > > > From: Mel Martinez [mailto:[EMAIL PROTECTED]] > > > Sent: Saturday, April 07, 2001 10:21 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [STATUS] Tomcat 3.2.2 > > > > > > > > > > > > Mark, > > > > > > Re: the problem with the fact that some jdk1.2.2 > > > implementations may have the bug and others may not. > > > > > > Could you possibly put a preamble in a static > > > initializer that explicitely tests the URL decoding of > > > some static strings? If the bug occurs, set a (static > > > final) flag? That would give you a simple (static > > > final) boolean test on whether to double the decoding > > > or not, which would be about as minimal a runtime > > > performance hit as you could hope for. > > > > > > Just a wild thought from left field. > > > > > > Mel > > > > > > --- Marc Saegesser <[EMAIL PROTECTED]> wrote: > > > > As usual, the problem turned out to be deeper then I > > > > first expected. > > > > > > > > Here's what happened. There was a bug in 3.2.1 that > > > > servlet paths and path > > > > info weren't being decoded as required by the spec. > > > > This was fixed in > > > > 3.2.2. > > > > > > > > It also turns out that there was bug in JDK1.2.2 > > > > that caused %HH escape > > > > characters in file: URLs to not be decoded. I > > > > originally thought the bug > > > > was in 1.3.0, but after re-reading the URL spec I > > > > accept that the bug was > > > > really in 1.2.2. The bottom line is that the > > > > behavior of file URLs is > > > > different on different versions of Java. > > > > > > > > Context.getResource() constructs a file: URL by >
RE: [STATUS] Tomcat 3.2.2
On Sat, 7 Apr 2001, Marc Saegesser wrote: > The problem really lies in the implementation of > sun.net.www.protocol.file.FileURLConnection. Costin's idea of creating a > Tomcat implementation that works the way we need it to work has some merit. > I'll look at what it would take implement a URLConnectionhandler. It seems the idea is not that good - URL is final, and changing the file: connection seems to be a bigger hack ( i.e. will affect all VMs, including the good ones ) than detecting a bad VM and fixing the URL. But on a second tought, and after a bit of reading in the Apache sources, I think we are on the wrong track. I think that instead of fixing the code to deal with all possible encoding tricks we should just report "invalid request" if we detect double encoding or %00 or anything suspicious ( Apache does that, we should do the same at least for consistency ). Of course, that means some files will not work - i.e. if you have a file named "foo%20bar%00" ( a valid file name - "foo bar" will work ), you'll not be able to request it. But I would rather have this as a bug than deal with security issues. Costin > > > -Original Message- > > From: Mel Martinez [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 07, 2001 10:21 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [STATUS] Tomcat 3.2.2 > > > > > > > > Mark, > > > > Re: the problem with the fact that some jdk1.2.2 > > implementations may have the bug and others may not. > > > > Could you possibly put a preamble in a static > > initializer that explicitely tests the URL decoding of > > some static strings? If the bug occurs, set a (static > > final) flag? That would give you a simple (static > > final) boolean test on whether to double the decoding > > or not, which would be about as minimal a runtime > > performance hit as you could hope for. > > > > Just a wild thought from left field. > > > > Mel > > > > --- Marc Saegesser <[EMAIL PROTECTED]> wrote: > > > As usual, the problem turned out to be deeper then I > > > first expected. > > > > > > Here's what happened. There was a bug in 3.2.1 that > > > servlet paths and path > > > info weren't being decoded as required by the spec. > > > This was fixed in > > > 3.2.2. > > > > > > It also turns out that there was bug in JDK1.2.2 > > > that caused %HH escape > > > characters in file: URLs to not be decoded. I > > > originally thought the bug > > > was in 1.3.0, but after re-reading the URL spec I > > > accept that the bug was > > > really in 1.2.2. The bottom line is that the > > > behavior of file URLs is > > > different on different versions of Java. > > > > > > Context.getResource() constructs a file: URL by > > > concatenating the context > > > root with the servlet path. On JDK1.3.0 systems, > > > this now results in the > > > servlet path getting decoded twice: once in > > > RequestUtil and once by URL. > > > Decoding URLs more than once causes all kinds of > > > security problems. > > > > > > So, given that file: URLs behave differently on > > > different system, we have to > > > adjust the input to the URL constructor in > > > Context.getResource() so that the > > > file names passed in on systems without the bug have > > > been URL encoded so > > > that the URL can then decode them and get the > > > correct file name. > > > > > > So now the question becomes determining if the > > > system has the file: URL bug. > > > I don't think you can just look at the version > > > number because not every > > > vendor's 1.2.2 implementation may be broken and > > > every vendor's 1.3.x > > > implementation may not be fixed. So it comes down > > > to checking the behavior > > > of URL to see what flavor you have. I've tried all > > > kinds of combinations of > > > toString(), toExternalForm(), sameFile(), etc. and > > > so far the only reliable > > > method I have for determining which version of URL > > > you have is to actually > > > use it to open an InputStream and see if it works. > > > For example a simple > > > routine could try to open file:%2e (i.e. the current > > > directory). If it gets > > > a FileNotFoundException then it assumes that it has > > > a broken URL > > > implementation, if
RE: [STATUS] Tomcat 3.2.2
This is similar to what I already implemented. The difficulty arises from the fact the problem is not apparent until you actually attempt to create the input stream. I tried lots of variations of creating URLs objects and then turning them into strings and there was no reliable way to detect the decoded/non-decode variations without creating the InputStream. The problem really lies in the implementation of sun.net.www.protocol.file.FileURLConnection. Costin's idea of creating a Tomcat implementation that works the way we need it to work has some merit. I'll look at what it would take implement a URLConnectionhandler. > -Original Message- > From: Mel Martinez [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 07, 2001 10:21 AM > To: [EMAIL PROTECTED] > Subject: RE: [STATUS] Tomcat 3.2.2 > > > > Mark, > > Re: the problem with the fact that some jdk1.2.2 > implementations may have the bug and others may not. > > Could you possibly put a preamble in a static > initializer that explicitely tests the URL decoding of > some static strings? If the bug occurs, set a (static > final) flag? That would give you a simple (static > final) boolean test on whether to double the decoding > or not, which would be about as minimal a runtime > performance hit as you could hope for. > > Just a wild thought from left field. > > Mel > > --- Marc Saegesser <[EMAIL PROTECTED]> wrote: > > As usual, the problem turned out to be deeper then I > > first expected. > > > > Here's what happened. There was a bug in 3.2.1 that > > servlet paths and path > > info weren't being decoded as required by the spec. > > This was fixed in > > 3.2.2. > > > > It also turns out that there was bug in JDK1.2.2 > > that caused %HH escape > > characters in file: URLs to not be decoded. I > > originally thought the bug > > was in 1.3.0, but after re-reading the URL spec I > > accept that the bug was > > really in 1.2.2. The bottom line is that the > > behavior of file URLs is > > different on different versions of Java. > > > > Context.getResource() constructs a file: URL by > > concatenating the context > > root with the servlet path. On JDK1.3.0 systems, > > this now results in the > > servlet path getting decoded twice: once in > > RequestUtil and once by URL. > > Decoding URLs more than once causes all kinds of > > security problems. > > > > So, given that file: URLs behave differently on > > different system, we have to > > adjust the input to the URL constructor in > > Context.getResource() so that the > > file names passed in on systems without the bug have > > been URL encoded so > > that the URL can then decode them and get the > > correct file name. > > > > So now the question becomes determining if the > > system has the file: URL bug. > > I don't think you can just look at the version > > number because not every > > vendor's 1.2.2 implementation may be broken and > > every vendor's 1.3.x > > implementation may not be fixed. So it comes down > > to checking the behavior > > of URL to see what flavor you have. I've tried all > > kinds of combinations of > > toString(), toExternalForm(), sameFile(), etc. and > > so far the only reliable > > method I have for determining which version of URL > > you have is to actually > > use it to open an InputStream and see if it works. > > For example a simple > > routine could try to open file:%2e (i.e. the current > > directory). If it gets > > a FileNotFoundException then it assumes that it has > > a broken URL > > implementation, if it doesn't get an exception then > > it assumes that the URL > > implementation is correct. Context.getResource() > > can now check if the URL > > implementation is broken or not and do the right > > thing. > > > > This fixes the security hole, but opens up a new > > kind of attack. A > > malicious user on a JDK1.2.2 server could create a > > file called %2e in > > Tomcat's working directory. This would cause Tomcat > > to not find resources > > that it legitimately should find. This better than > > exposing the entire > > server to prying eyes, but it still doesn't feel > > right. > > > > I'm going to commit the fix as I have it now so that > > others can review it > > and maybe come up with a better approach. I'm now > > planning to release beta > > 3 Saturday morning (central US ti
RE: [STATUS] Tomcat 3.2.2
Mark, Re: the problem with the fact that some jdk1.2.2 implementations may have the bug and others may not. Could you possibly put a preamble in a static initializer that explicitely tests the URL decoding of some static strings? If the bug occurs, set a (static final) flag? That would give you a simple (static final) boolean test on whether to double the decoding or not, which would be about as minimal a runtime performance hit as you could hope for. Just a wild thought from left field. Mel --- Marc Saegesser <[EMAIL PROTECTED]> wrote: > As usual, the problem turned out to be deeper then I > first expected. > > Here's what happened. There was a bug in 3.2.1 that > servlet paths and path > info weren't being decoded as required by the spec. > This was fixed in > 3.2.2. > > It also turns out that there was bug in JDK1.2.2 > that caused %HH escape > characters in file: URLs to not be decoded. I > originally thought the bug > was in 1.3.0, but after re-reading the URL spec I > accept that the bug was > really in 1.2.2. The bottom line is that the > behavior of file URLs is > different on different versions of Java. > > Context.getResource() constructs a file: URL by > concatenating the context > root with the servlet path. On JDK1.3.0 systems, > this now results in the > servlet path getting decoded twice: once in > RequestUtil and once by URL. > Decoding URLs more than once causes all kinds of > security problems. > > So, given that file: URLs behave differently on > different system, we have to > adjust the input to the URL constructor in > Context.getResource() so that the > file names passed in on systems without the bug have > been URL encoded so > that the URL can then decode them and get the > correct file name. > > So now the question becomes determining if the > system has the file: URL bug. > I don't think you can just look at the version > number because not every > vendor's 1.2.2 implementation may be broken and > every vendor's 1.3.x > implementation may not be fixed. So it comes down > to checking the behavior > of URL to see what flavor you have. I've tried all > kinds of combinations of > toString(), toExternalForm(), sameFile(), etc. and > so far the only reliable > method I have for determining which version of URL > you have is to actually > use it to open an InputStream and see if it works. > For example a simple > routine could try to open file:%2e (i.e. the current > directory). If it gets > a FileNotFoundException then it assumes that it has > a broken URL > implementation, if it doesn't get an exception then > it assumes that the URL > implementation is correct. Context.getResource() > can now check if the URL > implementation is broken or not and do the right > thing. > > This fixes the security hole, but opens up a new > kind of attack. A > malicious user on a JDK1.2.2 server could create a > file called %2e in > Tomcat's working directory. This would cause Tomcat > to not find resources > that it legitimately should find. This better than > exposing the entire > server to prying eyes, but it still doesn't feel > right. > > I'm going to commit the fix as I have it now so that > others can review it > and maybe come up with a better approach. I'm now > planning to release beta > 3 Saturday morning (central US time). > > > > > -Original Message- > > From: Marc Saegesser > [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 06, 2001 11:29 AM > > To: [EMAIL PROTECTED] > > Subject: [STATUS] Tomcat 3.2.2 > > > > > > I've got a fix for the URL double decode security > problem in Tomcat 3.2.2. > > I'm going to release Tomcat 3.2.2 beta 3 tonight > to make this fix publicly > > available. Because the only change in Beta 3 is > the security > > fix, this beta > > cycle will only be one week long. If no other > security issues are found, > > I'll call a vote for 3.2.2 final late next week. > > > > > > > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: [STATUS] Tomcat 3.2.2
Marc, What about removing the use of URL ? We can create a local URL object that works in a deterministic way - that would be much cleaner than guessing the OS and doing workarounds. Costin On Fri, 6 Apr 2001, Marc Saegesser wrote: > As usual, the problem turned out to be deeper then I first expected. > > Here's what happened. There was a bug in 3.2.1 that servlet paths and path > info weren't being decoded as required by the spec. This was fixed in > 3.2.2. > > It also turns out that there was bug in JDK1.2.2 that caused %HH escape > characters in file: URLs to not be decoded. I originally thought the bug > was in 1.3.0, but after re-reading the URL spec I accept that the bug was > really in 1.2.2. The bottom line is that the behavior of file URLs is > different on different versions of Java. > > Context.getResource() constructs a file: URL by concatenating the context > root with the servlet path. On JDK1.3.0 systems, this now results in the > servlet path getting decoded twice: once in RequestUtil and once by URL. > Decoding URLs more than once causes all kinds of security problems. > > So, given that file: URLs behave differently on different system, we have to > adjust the input to the URL constructor in Context.getResource() so that the > file names passed in on systems without the bug have been URL encoded so > that the URL can then decode them and get the correct file name. > > So now the question becomes determining if the system has the file: URL bug. > I don't think you can just look at the version number because not every > vendor's 1.2.2 implementation may be broken and every vendor's 1.3.x > implementation may not be fixed. So it comes down to checking the behavior > of URL to see what flavor you have. I've tried all kinds of combinations of > toString(), toExternalForm(), sameFile(), etc. and so far the only reliable > method I have for determining which version of URL you have is to actually > use it to open an InputStream and see if it works. For example a simple > routine could try to open file:%2e (i.e. the current directory). If it gets > a FileNotFoundException then it assumes that it has a broken URL > implementation, if it doesn't get an exception then it assumes that the URL > implementation is correct. Context.getResource() can now check if the URL > implementation is broken or not and do the right thing. > > This fixes the security hole, but opens up a new kind of attack. A > malicious user on a JDK1.2.2 server could create a file called %2e in > Tomcat's working directory. This would cause Tomcat to not find resources > that it legitimately should find. This better than exposing the entire > server to prying eyes, but it still doesn't feel right. > > I'm going to commit the fix as I have it now so that others can review it > and maybe come up with a better approach. I'm now planning to release beta > 3 Saturday morning (central US time). > > > > > -Original Message- > > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 06, 2001 11:29 AM > > To: [EMAIL PROTECTED] > > Subject: [STATUS] Tomcat 3.2.2 > > > > > > I've got a fix for the URL double decode security problem in Tomcat 3.2.2. > > I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly > > available. Because the only change in Beta 3 is the security > > fix, this beta > > cycle will only be one week long. If no other security issues are found, > > I'll call a vote for 3.2.2 final late next week. > > > > > > >
RE: [STATUS] Tomcat 3.2.2
As usual, the problem turned out to be deeper then I first expected. Here's what happened. There was a bug in 3.2.1 that servlet paths and path info weren't being decoded as required by the spec. This was fixed in 3.2.2. It also turns out that there was bug in JDK1.2.2 that caused %HH escape characters in file: URLs to not be decoded. I originally thought the bug was in 1.3.0, but after re-reading the URL spec I accept that the bug was really in 1.2.2. The bottom line is that the behavior of file URLs is different on different versions of Java. Context.getResource() constructs a file: URL by concatenating the context root with the servlet path. On JDK1.3.0 systems, this now results in the servlet path getting decoded twice: once in RequestUtil and once by URL. Decoding URLs more than once causes all kinds of security problems. So, given that file: URLs behave differently on different system, we have to adjust the input to the URL constructor in Context.getResource() so that the file names passed in on systems without the bug have been URL encoded so that the URL can then decode them and get the correct file name. So now the question becomes determining if the system has the file: URL bug. I don't think you can just look at the version number because not every vendor's 1.2.2 implementation may be broken and every vendor's 1.3.x implementation may not be fixed. So it comes down to checking the behavior of URL to see what flavor you have. I've tried all kinds of combinations of toString(), toExternalForm(), sameFile(), etc. and so far the only reliable method I have for determining which version of URL you have is to actually use it to open an InputStream and see if it works. For example a simple routine could try to open file:%2e (i.e. the current directory). If it gets a FileNotFoundException then it assumes that it has a broken URL implementation, if it doesn't get an exception then it assumes that the URL implementation is correct. Context.getResource() can now check if the URL implementation is broken or not and do the right thing. This fixes the security hole, but opens up a new kind of attack. A malicious user on a JDK1.2.2 server could create a file called %2e in Tomcat's working directory. This would cause Tomcat to not find resources that it legitimately should find. This better than exposing the entire server to prying eyes, but it still doesn't feel right. I'm going to commit the fix as I have it now so that others can review it and maybe come up with a better approach. I'm now planning to release beta 3 Saturday morning (central US time). > -Original Message- > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 06, 2001 11:29 AM > To: [EMAIL PROTECTED] > Subject: [STATUS] Tomcat 3.2.2 > > > I've got a fix for the URL double decode security problem in Tomcat 3.2.2. > I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly > available. Because the only change in Beta 3 is the security > fix, this beta > cycle will only be one week long. If no other security issues are found, > I'll call a vote for 3.2.2 final late next week. > > >
RE: [STATUS] Tomcat 3.2.2
>I've got a fix for the URL double decode security problem in >Tomcat 3.2.2. >I'm going to release Tomcat 3.2.2 beta 3 tonight to make this >fix publicly >available. Because the only change in Beta 3 is the security >fix, this beta >cycle will only be one week long. If no other security issues >are found, >I'll call a vote for 3.2.2 final late next week. I'll do the linux RPM and binaries mod_jk :)
[STATUS] Tomcat 3.2.2
I've got a fix for the URL double decode security problem in Tomcat 3.2.2. I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly available. Because the only change in Beta 3 is the security fix, this beta cycle will only be one week long. If no other security issues are found, I'll call a vote for 3.2.2 final late next week.
RE: [STATUS] Tomcat 3.2.2 beta 2
Petr, Bug 875 may be related to what your seeing. I can duplicate this one. Bug 463 looks like it might be the same problem. Neither of these will be addressed in Tomcat 3.2.2, but once that release is out the code freeze will be lifted an we can work on addressing these and other issues. I don't see a bug report about entering Japanese text in the URL. Note that RFD2396 doesn't support non-ASCII characters in URIs and also doesn't specify what character encoding should be used for %HH escaped characters. The Internationalization resources on the W3C site say that the preferred encoding is UTF-8. Can you verify that the Japanese characters you enter in the URL are actually being correctly encoded in the HTTP request? http://www.w3.org/International/O-URL-and-ident.html Marc Saegesser > -Original Message- > From: Petr Jiricka [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 27, 2001 5:30 AM > To: [EMAIL PROTECTED] > Subject: Re: [STATUS] Tomcat 3.2.2 beta 2 > > > Marc, > > thanks many times for making this happen. > > I would like to ask about the status of one particular issue. > This is a long > outstanding issue whose one effect is that you can not serve > files with file > names containing multibyte characters. I can still reproduce this > problem in > 3.2.2 b2. I talked to Costin about this some time ago, and from what I > understand, he thinks this problem is difficult to tackle in the > 3.2 source > base, and that the solution is only possible in 3.3 and 4.0, so I > don't much > hope that this can be fixed for 3.2.2 final. Either way, I think > this should > be at least documented in the release notes. > > To reproduce: > 1) Create a file under the document base and name it so it contains > characters in a multibyte character set (Japanese, Korean, ...) > 2) Type its URL into a web browser > > I didn't see a bugzilla entry for this, should I create one ? > > Costin, do you know anything about this issue ? Is my description > accurate ? > > Thanks > > Petr > > > ----- Original Message - > From: "Marc Saegesser" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 24, 2001 12:02 AM > Subject: [STATUS] Tomcat 3.2.2 beta 2 > > > > The tomcat_322_b2 tag is now available. The binary and source > distributions > > have been uploaded. I've got a couple more download tests to finish > before > > I update the website and send the announcement messages. > > > > If anyone has binaries that they want included in the > distribution please > > send them to me and I'll add them to the download area. > > > > Thanks for everyone help getting this release wrapped up. > >
Re: [STATUS] Tomcat 3.2.2 beta 2
Marc, thanks many times for making this happen. I would like to ask about the status of one particular issue. This is a long outstanding issue whose one effect is that you can not serve files with file names containing multibyte characters. I can still reproduce this problem in 3.2.2 b2. I talked to Costin about this some time ago, and from what I understand, he thinks this problem is difficult to tackle in the 3.2 source base, and that the solution is only possible in 3.3 and 4.0, so I don't much hope that this can be fixed for 3.2.2 final. Either way, I think this should be at least documented in the release notes. To reproduce: 1) Create a file under the document base and name it so it contains characters in a multibyte character set (Japanese, Korean, ...) 2) Type its URL into a web browser I didn't see a bugzilla entry for this, should I create one ? Costin, do you know anything about this issue ? Is my description accurate ? Thanks Petr - Original Message - From: "Marc Saegesser" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 24, 2001 12:02 AM Subject: [STATUS] Tomcat 3.2.2 beta 2 > The tomcat_322_b2 tag is now available. The binary and source distributions > have been uploaded. I've got a couple more download tests to finish before > I update the website and send the announcement messages. > > If anyone has binaries that they want included in the distribution please > send them to me and I'll add them to the download area. > > Thanks for everyone help getting this release wrapped up. >
[STATUS] Tomcat 3.2.2 beta 2
The tomcat_322_b2 tag is now available. The binary and source distributions have been uploaded. I've got a couple more download tests to finish before I update the website and send the announcement messages. If anyone has binaries that they want included in the distribution please send them to me and I'll add them to the download area. Thanks for everyone help getting this release wrapped up.
Re: [STATUS] Tomcat 3.2.2
Marc, I just want to say that it is fantastic that you have managed to corral all those loose bug reports. -Dan Marc Saegesser wrote: > > Well, it took longer than I had hoped, but we have finally managed to review > *all* open bug reports against Tomcat-3! The only reports left in the NEW > state are those specifically opened against Tomcat 3.3. All the others have > either been closed as FIXED, WORKSFORME or INVALID. A big THANK YOU to > everyone who helped make this happen. > > My plan is to use tomorrow, Thursday (3/22/01) for some final testing. On > Friday morning (Central US time) I will tag and build Tomcat 3.2.2 beta 2. > This beta will last two weeks, during which time the only commits to the > tomcat_32 branch will be for fixing critical bugs identified during the beta > period. > > At the end of the beta period I will call a vote for the release of Tomcat > 3.2.2. > > Marc Saegesser -- Dan Milstein // [EMAIL PROTECTED]
[STATUS] Tomcat 3.2.2
Well, it took longer than I had hoped, but we have finally managed to review *all* open bug reports against Tomcat-3! The only reports left in the NEW state are those specifically opened against Tomcat 3.3. All the others have either been closed as FIXED, WORKSFORME or INVALID. A big THANK YOU to everyone who helped make this happen. My plan is to use tomorrow, Thursday (3/22/01) for some final testing. On Friday morning (Central US time) I will tag and build Tomcat 3.2.2 beta 2. This beta will last two weeks, during which time the only commits to the tomcat_32 branch will be for fixing critical bugs identified during the beta period. At the end of the beta period I will call a vote for the release of Tomcat 3.2.2. Marc Saegesser
[STATUS] Tomcat 3.2.2
The original plan was to create the second beta release for Tomcat 3.2.2 today. We have been making very good progress reviewing all the open Bugzilla items, but there are still quite a few left that have not been reviewed. In the process of this review we've found several bugs that were deemed important enough to fix prior to finalizing the release. These involved crashes, or spec non-compliance. We are within striking distance of completing this review so I'm going to hold off creating the Tomcat 3.2.2 beta 2 release for a few more days to allow this process to complete. Marc Saegesser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]