DO NOT REPLY [Bug 48192] Allow to specify the SSLSocket class in connector tag of server.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=48192 Ralf Hauser changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #3 from Ralf Hauser 2009-11-20 00:34:31 UTC --- yes, there are also other purposes, e.g. we might get a forensics requirement that we might have to record the exact handshake because in the AS-IS we see the ssl session id and the client certs, but we cannot prove to an independent third party that whoever connected to our tomcat really was in possession of the corresponding private key -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL MITM status update
Sounds good to me, thanks! Info not yet ready for users@: On d...@httpd there is discusion, whether to fix request splicing attacks by dropping the buffer, therefore effectively not allowing to combine a partial request before reneg with the request coming after the reneg. Although we don't know yet, whether that is the only attack possible, all scenarios I have heard of use request splicing. Discussion and testing whether this breaks clients still has to proceed. I think it's not a reason to prevent a release here, but there might be more fine grained workarounds for the attack in combination with server-initiated reneg feasable. Regards, Rainer On 20.11.2009 00:20, Mark Thomas wrote: > Feedback / comments on the info below. I'd like to get it out to users@ > and announce@ fairly soon. > > Cheers, > > Mark > > === > > Overview > > > Work on the root cause is progressing but is still in a state of flux. > The purpose of this update is provide information on the current > understanding so users are better informed when making decisions > regarding risk mitigation for this issue in their environment. > > > BIO Connector > = > > The HTTP BIO connector that ships with 6.0.20 and 5.5.28 supports client > and server initiated negotiation and is vulnerable to CVE-2009-3555. > > A patch [1] has been applied to trunk, 6.0.x and 5.5.x that provides an > option to disable renegotiation. This patch has an issue in that it uses > an asynchronous callback to close the connection when a handshake is > detected. It is theoretically possible for an attack to complete before > the connection is closed. When negotiation is disabled, both server and > client initiated attempts to renegotiate are logged. > > An updated patch [2] has been applied to trunk and proposed for 6.0.x > and 5.5.x that resolves the asynchronous concerns but only logs server > initiated renegotiation. > > Users of 6.0.20, 5.5.28 and earlier versions can apply either of the > patches. It will be necessary to build Tomcat from source to use these > patches. > > Testing with both these patches has shown that using the connector > attributes clientAuth="want" and allowUnsafeLegacyRenegotiation="false" > provides a similar user experience during negotiation to > clientAuth="false" and allowUnsafeLegacyRenegotiation="true" although > this may vary by application. > > It is anticipated that 6.0.21 and 5.5.29 releases will be made once the > situation stabilises and the Tomcat development team is confident that > further changes will not be required. > > > NIO Connector > = > > The HTTP NIO connector that ships with 6.0.20 and 5.5.28 does not > support client or server initiated renegotiation and is therefore not > vulnerable to CVE-2009-3555. > > As and when negotiation support is added to the NIO connector, it will > support the allowUnsafeLegacyRenegotiation connector attribute and > behave in a similar manner to the HTTP BIO connector. > > > APR / native Connector > == > > Behaviour of the APR/native connector depends on the version of the > APR/native connector and on the version of OpenSSL that the connector is > build with. Versions prior to APR/native 1.1.16 are not discussed. > > The windows binaries available from the ASF have been built with the > following OpenSSL versions: > > APR/native OpenSSL > 1.1.16 0.9.8i > 1.1.17 0.9.8l > 1.1.18 0.9.8k - TBC > > Any version of the APR/native connector built with OpenSSl 0.9.8l will > not support client or server initiated negotiation and will, therefore, > not be vulnerable to CVE-2009-3555. > > Client initiated negotiation is supported in 1.1.16 and 1.1.17. These > versions are, therefore, vulnerable to CVE-2009-3555 unless built with > OpenSSL 0.9.8l. > > Client initiated negotiation has been disabled in 1.1.18. Therefore, > this version is not vulnerable to CVE-2009-3555 via client initiated > renegotiation although it may still be vulnerable via server initiated > renegotiation. > > Server initiated renegotiation is supported in 1.1.17 onwards. > Therefore, 1.1.17 onwards is vulnerable to CVE-2009-3555 via server > initiated renegotiation unless the APR/native connector is built with > OpenSSL 0.9.8l. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL MITM status update
Rainer Jung wrote: > Sounds good to me, thanks! > > Info not yet ready for users@: On d...@httpd there is discusion, whether > to fix request splicing attacks by dropping the buffer, therefore > effectively not allowing to combine a partial request before reneg with > the request coming after the reneg. Although we don't know yet, whether > that is the only attack possible, all scenarios I have heard of use > request splicing. > > Discussion and testing whether this breaks clients still has to proceed. > I think it's not a reason to prevent a release here, but there might be > more fine grained workarounds for the attack in combination with > server-initiated reneg feasable. Thanks. I'll add something to the first paragraph along the lines of: "Discussion is focussed on workarounds that could be applied that would allow server initiated renegotiation without exposing the participant to the vulnerability described in CVE-2009-3555." Unless anyone complains, I'll send this out later today. Mark > Regards, > > Rainer > > On 20.11.2009 00:20, Mark Thomas wrote: >> Feedback / comments on the info below. I'd like to get it out to users@ >> and announce@ fairly soon. >> >> Cheers, >> >> Mark >> >> === >> >> Overview >> >> >> Work on the root cause is progressing but is still in a state of flux. >> The purpose of this update is provide information on the current >> understanding so users are better informed when making decisions >> regarding risk mitigation for this issue in their environment. >> >> >> BIO Connector >> = >> >> The HTTP BIO connector that ships with 6.0.20 and 5.5.28 supports client >> and server initiated negotiation and is vulnerable to CVE-2009-3555. >> >> A patch [1] has been applied to trunk, 6.0.x and 5.5.x that provides an >> option to disable renegotiation. This patch has an issue in that it uses >> an asynchronous callback to close the connection when a handshake is >> detected. It is theoretically possible for an attack to complete before >> the connection is closed. When negotiation is disabled, both server and >> client initiated attempts to renegotiate are logged. >> >> An updated patch [2] has been applied to trunk and proposed for 6.0.x >> and 5.5.x that resolves the asynchronous concerns but only logs server >> initiated renegotiation. >> >> Users of 6.0.20, 5.5.28 and earlier versions can apply either of the >> patches. It will be necessary to build Tomcat from source to use these >> patches. >> >> Testing with both these patches has shown that using the connector >> attributes clientAuth="want" and allowUnsafeLegacyRenegotiation="false" >> provides a similar user experience during negotiation to >> clientAuth="false" and allowUnsafeLegacyRenegotiation="true" although >> this may vary by application. >> >> It is anticipated that 6.0.21 and 5.5.29 releases will be made once the >> situation stabilises and the Tomcat development team is confident that >> further changes will not be required. >> >> >> NIO Connector >> = >> >> The HTTP NIO connector that ships with 6.0.20 and 5.5.28 does not >> support client or server initiated renegotiation and is therefore not >> vulnerable to CVE-2009-3555. >> >> As and when negotiation support is added to the NIO connector, it will >> support the allowUnsafeLegacyRenegotiation connector attribute and >> behave in a similar manner to the HTTP BIO connector. >> >> >> APR / native Connector >> == >> >> Behaviour of the APR/native connector depends on the version of the >> APR/native connector and on the version of OpenSSL that the connector is >> build with. Versions prior to APR/native 1.1.16 are not discussed. >> >> The windows binaries available from the ASF have been built with the >> following OpenSSL versions: >> >> APR/native OpenSSL >> 1.1.16 0.9.8i >> 1.1.17 0.9.8l >> 1.1.18 0.9.8k - TBC >> >> Any version of the APR/native connector built with OpenSSl 0.9.8l will >> not support client or server initiated negotiation and will, therefore, >> not be vulnerable to CVE-2009-3555. >> >> Client initiated negotiation is supported in 1.1.16 and 1.1.17. These >> versions are, therefore, vulnerable to CVE-2009-3555 unless built with >> OpenSSL 0.9.8l. >> >> Client initiated negotiation has been disabled in 1.1.18. Therefore, >> this version is not vulnerable to CVE-2009-3555 via client initiated >> renegotiation although it may still be vulnerable via server initiated >> renegotiation. >> >> Server initiated renegotiation is supported in 1.1.17 onwards. >> Therefore, 1.1.17 onwards is vulnerable to CVE-2009-3555 via server >> initiated renegotiation unless the APR/native connector is built with >> OpenSSL 0.9.8l. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > -
Re: svn commit: r882320 - in /tomcat/trunk/java/org/apache/tomcat/util/net/jsse: JSSESocketFactory.java JSSESupport.java
Bill Barker wrote: > This looks like it should work (haven't tested it yet), but hoping that > there are people that can test on non-Sun JVMs to see if there could be > problems. This patch is a little heavy on knowing how the JVM implements > things :(. Yes, I was testing on a recent Sun 1.6 JVM. I just tested this with a recent 1.6 IBM JVM with the same results so things are looking good. I've got access to some HP-UX boxes via work so I'll test it on that too and report back. Mark > > wrote in message > news:20091119220644.2d8f42388...@eris.apache.org... >> Author: markt >> Date: Thu Nov 19 22:06:43 2009 >> New Revision: 882320 >> >> URL: http://svn.apache.org/viewvc?rev=882320&view=rev >> Log: >> Improve workaround for CVE-2009-3555 >> On the plus side, it doesn't rely on an async event to close the >> connection >> On the down side, I haven't yet found a way to log client initiated >> handshakes before they get closed >> >> Modified: >> >> tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java >>tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java >> >> Modified: >> tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java >> URL: >> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?rev=882320&r1=882319&r2=882320&view=diff >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48236] another workaround for CVE-2009-3555 for the BIO connector
https://issues.apache.org/bugzilla/show_bug.cgi?id=48236 --- Comment #5 from Mark Thomas 2009-11-20 01:48:50 GMT --- Nothing formal, and the nature of the tests is such it might take a little longer than usual to set up something with the Tomcat JUnit tests. My testing uses a simple webapp that uses CLIENT-CERT and has one JSP that is protected by a security constraint. To test client renegotiation, I use openssl s_client and the R command To test server renegotiation, I use Firefox or IE and browse between the Tomcat homepage and the protected page. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48248] New: tribes.group.interceptors.MessageDispatchInterceptor.run should be volatile
https://issues.apache.org/bugzilla/show_bug.cgi?id=48248 Summary: tribes.group.interceptors.MessageDispatchInterceptor.r un should be volatile Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: s...@apache.org org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.run should be volatile, as it is used to communicate between running threads. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48248] tribes.group.interceptors.MessageDispatchInterceptor.run should be volatile
https://issues.apache.org/bugzilla/show_bug.cgi?id=48248 --- Comment #1 from Sebb 2009-11-20 05:02:32 UTC --- Ditto for: org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.running org.apache.catalina.tribes.group.GroupChannel.HeartbeatThread.doRun org.apache.catalina.tribes.membership.McastServiceImpl.doRunReceiver org.apache.catalina.tribes.membership.McastServiceImpl.doRunSender org.apache.catalina.tribes.membership.McastServiceImpl.RecoveryThread.running -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48249] New: org.apache.tomcat.util.net.NioBlockingSelector.BlockPoller.run <= volatile
https://issues.apache.org/bugzilla/show_bug.cgi?id=48249 Summary: org.apache.tomcat.util.net.NioBlockingSelector.BlockPo ller.run <= volatile Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: s...@apache.org org.apache.tomcat.util.net.NioBlockingSelector.BlockPoller.run should be volatile, as it is used to communicate between running threads. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48250] New: Character Encoding on HTTP Conector
https://issues.apache.org/bugzilla/show_bug.cgi?id=48250 Summary: Character Encoding on HTTP Conector Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: Connector:HTTP AssignedTo: dev@tomcat.apache.org ReportedBy: dan.bag...@metadatatechnology.com This bug is present on the following Systems Server version: Apache Tomcat/5.5.20 Server built: May 8 2007 10:23:38 Server number: 5.5.20.0 OS Name:Linux OS Version: 2.6.9-78.0.13.ELsmp Architecture: amd64 JVM Version:1.5.0_16-b02 JVM Vendor: Sun Microsystems Inc. and Version: Apache Tomcat/5.0.28 But works on all versions of Tomcat in windows and version 6 of Tomcat on Linux. Using the supplied characters filters from the sample applications in the tomcat distribution, and setting the character encoding to UTF-8. Accented characters from the stream are corrupted. This only happens for plain text, XML documents streams are ok where the encoding is set at the top of the document. example text stream UNA:+.? ' UNB+UNOC:3+5B0+5B0+091008:1202+IREF020810++SDMX-EDI' UNH+MREF01+GESMES:2:1:E6' BGM+73' NAD+Z02+BIS-EDI' NAD+MR+5B0' NAD+MS+5B0' VLI+CL_AVAILABILITY+++Availability' CDV+A' FTX+ACM+++FREE' CDV+B' FTX+ACM+++BIS only, Cônstant not for publication' -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r882547 - /tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/ParameterParser.java
Author: markt
Date: Fri Nov 20 13:42:34 2009
New Revision: 882547
URL: http://svn.apache.org/viewvc?rev=882547&view=rev
Log:
Fix error in previous commit
Modified:
tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/ParameterParser.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/ParameterParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/ParameterParser.java?rev=882547&r1=882546&r2=882547&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/ParameterParser.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/ParameterParser.java
Fri Nov 20 13:42:34 2009
@@ -295,7 +295,7 @@
int length,
char separator) {
-if (chars == null) {
+if (inputChars == null) {
return new HashMap();
}
HashMap params = new HashMap();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r882550 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/deploy/ java/org/apache/catalina/manager/
Author: markt
Date: Fri Nov 20 13:46:21 2009
New Revision: 882550
URL: http://svn.apache.org/viewvc?rev=882550&view=rev
Log:
Start to hook-up the commons-file upload port to the Servlet3 file upload API
- Make sure the upload config is available when required
- Start to migrate the HTML manager to the upload API
Modified:
tomcat/trunk/java/org/apache/catalina/Wrapper.java
tomcat/trunk/java/org/apache/catalina/connector/Request.java
tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java
tomcat/trunk/java/org/apache/catalina/deploy/MultipartDef.java
tomcat/trunk/java/org/apache/catalina/deploy/ServletDef.java
tomcat/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
tomcat/trunk/java/org/apache/catalina/startup/WebRuleSet.java
tomcat/trunk/java/org/apache/catalina/startup/WebXml.java
tomcat/trunk/webapps/manager/WEB-INF/web.xml
Modified: tomcat/trunk/java/org/apache/catalina/Wrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Wrapper.java?rev=882550&r1=882549&r2=882550&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Wrapper.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Wrapper.java Fri Nov 20 13:46:21 2009
@@ -19,6 +19,7 @@
package org.apache.catalina;
+import javax.servlet.MultipartConfigElement;
import javax.servlet.Servlet;
import javax.servlet.ServletException;
import javax.servlet.UnavailableException;
@@ -334,4 +335,17 @@
public void unload() throws ServletException;
+/**
+ * Get the multi-part configuration for the associated servlet. If no
+ * multi-part configuration has been defined, then null will
be
+ * returned.
+ */
+public MultipartConfigElement getMultipartConfig();
+
+
+/**
+ * Set the multi-part configuration for the associated servlet. To clear
the
+ * multi-part configuration specify null as the new value.
+ */
+public void setMultipartConfig(MultipartConfigElement multipartConfig);
}
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=882550&r1=882549&r2=882550&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Nov 20
13:46:21 2009
@@ -27,6 +27,7 @@
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Collection;
+import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Iterator;
@@ -39,6 +40,7 @@
import javax.servlet.AsyncContext;
import javax.servlet.DispatcherType;
import javax.servlet.FilterChain;
+import javax.servlet.MultipartConfigElement;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
@@ -77,8 +79,10 @@
import org.apache.tomcat.util.http.FastHttpDateFormat;
import org.apache.tomcat.util.http.Parameters;
import org.apache.tomcat.util.http.ServerCookie;
+import org.apache.tomcat.util.http.fileupload.FileUploadBase;
import org.apache.tomcat.util.http.mapper.MappingData;
import org.apache.tomcat.util.res.StringManager;
+import org.apache.tools.ant.util.CollectionUtils;
/**
@@ -2382,8 +2386,20 @@
public Collection getParts() throws IOException,
IllegalStateException,
ServletException {
+
+String contentType = getContentType();
+if (contentType == null ||
+!contentType.startsWith(FileUploadBase.MULTIPART_FORM_DATA)) {
+return Collections.emptyList();
+}
+
+MultipartConfigElement mce = getWrapper().getMultipartConfig();
+if (mce == null) {
+return Collections.emptyList();
+}
+
// TODO SERVLET3 - file upload
-return null;
+return Collections.emptyList();
}
public Part getPart(String name) throws IOException, IllegalStateException,
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java?rev=882550&r1=882549&r2=882550&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java Fri Nov 20
13:46:21 2009
@@ -35,6 +35,7 @@
import javax.management.NotificationFilter;
import javax.management.NotificationListener;
import javax.management.ObjectName;
+import javax.servlet.MultipartConfigElement;
import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
@@ -255,6 +256
DO NOT REPLY [Bug 48252] New: StackOverflowError in NioEndpoint.setProperty when setting jkHome
https://issues.apache.org/bugzilla/show_bug.cgi?id=48252 Summary: StackOverflowError in NioEndpoint.setProperty when setting jkHome Product: Tomcat 6 Version: 6.0.20 Platform: PC OS/Version: Windows Vista Status: NEW Severity: normal Priority: P2 Component: Connectors AssignedTo: dev@tomcat.apache.org ReportedBy: james.dob...@nexj.com - Noticed only when running in debugger with breakpoint set for StackOverflowError. - The error is translated by Java's reflection mechanism to an InvocationTargetException, which is caught and silently ignored by IntrospectionUtils. - Connector.initialize() sets jkHome property on Http11NioProtocol. - Http11NioProtocol sets jkHome property on NioEndpoint. - NioEndpoint recursively invokes its own setProperty method via IntrospectionUtils.setProperty, causing the stack overflow. - Using embedded Tomcat. - Using Nio connector. Does not happen for standard connector. - Happens in 6.0.18 and 6.0.20; haven't tested with earlier versions. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL MITM status update
On 11/19/2009 04:20 PM, Mark Thomas wrote: and 5.5.28 does not don't think there is a HTTP NIO in 5.5.x Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48252] StackOverflowError in NioEndpoint.setProperty when setting jkHome
https://issues.apache.org/bugzilla/show_bug.cgi?id=48252 --- Comment #1 from Filip Hanik 2009-11-20 08:47:26 UTC --- Created an attachment (id=24573) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24573) Tomcat 6.0 patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r882638 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik Date: Fri Nov 20 16:48:29 2009 New Revision: 882638 URL: http://svn.apache.org/viewvc?rev=882638&view=rev Log: bugfix Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=882638&r1=882637&r2=882638&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Nov 20 16:48:29 2009 @@ -165,6 +165,7 @@ shutdown and delayed resources still trying to log http://svn.apache.org/viewvc?rev=666232&view=rev +1: kkolinko, markt + +1: fhanik - I would add in http://svn.apache.org/viewvc?rev=881396&view=rev -1: * Make FileHandler.java extensible @@ -191,6 +192,8 @@ -0: markt for all SBuilder->SBuffer patches. Code cleanup is fine in trunk but no need to backport it -0: funkman + -1: Is there a real benefit, other than clouding the revision history? ;) + I'd consider 6.0.x to be in maintenance mode not clean up/refactor mode. The patches, as well as patches for individual files inside them, are independent of each other. Vote for as many as you want. @@ -404,3 +407,9 @@ http://people.apache.org/~markt/patches/2009-11-20-cve2009-3555-v2.patch +1: markt -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48252 + Patch attached to BZ + +1: fhanik + -1: + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r882640 - in /tomcat/trunk/java/org/apache/tomcat/util: IntrospectionUtils.java net/AbstractEndpoint.java
Author: fhanik
Date: Fri Nov 20 16:57:31 2009
New Revision: 882640
URL: http://svn.apache.org/viewvc?rev=882640&view=rev
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48252
Fix potential recursion
Modified:
tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java?rev=882640&r1=882639&r2=882640&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java Fri Nov 20
16:57:31 2009
@@ -258,6 +258,9 @@
* you can have setDebug(1).
*/
public static boolean setProperty(Object o, String name, String value) {
+return setProperty(o,name,value,true);
+}
+public static boolean setProperty(Object o, String name, String
value,boolean invokeSetProperty) {
if (log.isDebugEnabled())
log.debug("IntrospectionUtils: setProperty(" +
o.getClass() + " " + name + "=" + value + ")");
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=882640&r1=882639&r2=882640&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Fri Nov
20 16:57:31 2009
@@ -312,7 +312,7 @@
if (name.startsWith(socketName)) {
return IntrospectionUtils.setProperty(socketProperties,
name.substring(socketName.length()), value);
} else {
-return IntrospectionUtils.setProperty(this,name,value);
+return IntrospectionUtils.setProperty(this,name,value,false);
}
}catch ( Exception x ) {
log.error("Unable to set attribute \""+name+"\" to
\""+value+"\"",x);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL MITM status update
Filip Hanik - Dev Lists wrote: > On 11/19/2009 04:20 PM, Mark Thomas wrote: >> and 5.5.28 does not >> > don't think there is a HTTP NIO in 5.5.x There isn't. I'll remove that reference. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48252] StackOverflowError in NioEndpoint.setProperty when setting jkHome
https://issues.apache.org/bugzilla/show_bug.cgi?id=48252 --- Comment #2 from James Dobson 2009-11-20 09:26:52 UTC --- Works for me, thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48191] Problem with mod_jk 1.2.28 - Can not render up the page on browser after a long wait
https://issues.apache.org/bugzilla/show_bug.cgi?id=48191 --- Comment #3 from thomas200...@yahoo.de 2009-11-20 09:28:10 UTC --- Further infomation: I took out the socket_timeout and reply_timeout. Here again my workers.properties: worker.worker_portfolio_son1.connection_pool_timeout=600 worker.worker_portfolio_son1.socket_keepalive=True worker.worker_portfolio_son1.lbfactor=1 worker.worker_portfolio_son1.type=ajp13 worker.worker_portfolio_son1.port=8009 worker.worker_portfolio_son1.host=appl-portfolio-test.mycom.com worker.worker_portfolio_son1.sticky_session=True I can't see the errno=11 in the mod_jk.log now. As I said in my last post, the developer changed the program so it will not return PDF-stream but simply plain text. What I get is posted in my former post. (my original post by Apache - User: http://old.nabble.com/A-question-about-mod_jk-1.2.28-configuration-to26264069.html#a26440263) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48191] Problem with mod_jk 1.2.28 - Can not render up the page on browser after a long wait
https://issues.apache.org/bugzilla/show_bug.cgi?id=48191 --- Comment #4 from Rainer Jung 2009-11-20 10:57:11 UTC --- OK, so we know, that this problem here (errno=11 during read) comes from the socket_timeout. Concerning your other observation: that is a totally different problem, even if it looks the same to you. There you send a tiny html content and the JK log shows, that we return the content, but the browser is not showing it. There are multiple reasons possible, from invalid content send up to MSIE behaviour. Try again using a simple commandline http client like wget or curl. If they show the content, then there's not bug with mod_jk. If you still think there's a problem in that html use case, please open another issue. The case with socket_timeout set and resulting in errno=11 will be handled here. We know enough about it now to fix it :) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r882690 - in /tomcat/trunk/java: javax/servlet/http/ org/apache/catalina/connector/ org/apache/catalina/core/ org/apache/catalina/manager/ org/apache/catalina/startup/ org/apache/tomcat/ut
Author: markt
Date: Fri Nov 20 19:27:11 2009
New Revision: 882690
URL: http://svn.apache.org/viewvc?rev=882690&view=rev
Log:
Complete the FileUpload implementation and use it for the html manager app.
Added:
tomcat/trunk/java/org/apache/catalina/core/StandardPart.java (with props)
Modified:
tomcat/trunk/java/javax/servlet/http/HttpServletRequest.java
tomcat/trunk/java/javax/servlet/http/Part.java
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/connector/Request.java
tomcat/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
tomcat/trunk/java/org/apache/catalina/startup/WebXml.java
tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/FileUploadBase.java
Modified: tomcat/trunk/java/javax/servlet/http/HttpServletRequest.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/http/HttpServletRequest.java?rev=882690&r1=882689&r2=882690&view=diff
==
--- tomcat/trunk/java/javax/servlet/http/HttpServletRequest.java (original)
+++ tomcat/trunk/java/javax/servlet/http/HttpServletRequest.java Fri Nov 20
19:27:11 2009
@@ -679,7 +679,11 @@
*
* @param username
* @param password
- * @throws ServletException
+ * @throws ServletException If any of {...@link #getRemoteUser()},
+ * {...@link #getUserPrincipal()} or {...@link #getAuthType()} are
+ * non-null, if the configured authenticator does not support
+ * user name and password authentication or if the authentication
+ * fails
* @since Servlet 3.0
* TODO SERVLET3 - Add comments
*/
@@ -689,7 +693,7 @@
/**
*
- * @throws ServletException
+ * @throws ServletException If the logout fails
* @since Servlet 3.0
* TODO SERVLET3 - Add comments
*/
Modified: tomcat/trunk/java/javax/servlet/http/Part.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/http/Part.java?rev=882690&r1=882689&r2=882690&view=diff
==
--- tomcat/trunk/java/javax/servlet/http/Part.java (original)
+++ tomcat/trunk/java/javax/servlet/http/Part.java Fri Nov 20 19:27:11 2009
@@ -31,6 +31,13 @@
public long getSize();
public void write(String fileName) throws IOException;
public void delete() throws IOException;
+
+/**
+ * Obtains the value of the specified mime header for the part.
+ * @param name Header name
+ * @return The header value or null if the header is not
+ * present
+ */
public String getHeader(String name);
public Collection getHeaders(String name);
public Collection getHeaderNames();
Modified:
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties?rev=882690&r1=882689&r2=882690&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties Fri
Nov 20 19:27:11 2009
@@ -66,6 +66,7 @@
coyoteRequest.noPasswordLogin=The authentication mechanism configured for this
context does not support user name and password authentication
coyoteRequest.authFail=The authentication of user {0} was not successful
coyoteRequest.authenticate.ise=Cannot call authenticate() after the reponse
has been committed
+coyoteRequest.uploadLocationInvalid=The temporary upload location [{0}] is not
valid
requestFacade.nullRequest=The request object has been recycled and is no
longer associated with this facade
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=882690&r1=882689&r2=882690&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Nov 20
19:27:11 2009
@@ -20,6 +20,7 @@
import java.io.BufferedReader;
+import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.UnsupportedEncodingException;
@@ -31,6 +32,7 @@
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Iterator;
+import java.util.List;
import java.util.Locale;
import java.util.Map;
import java.util.TimeZone;
@@ -65,12 +67,14 @@
import org.apache.catalina.Wrapper;
import org.apache.catalina.core.ApplicationSessionCookieConfig;
import org.apache.catalina.core.AsyncContextImpl;
+import org.apache.catalina.core.StandardPart;
import org.apache.catalina.deploy.LoginConfig;
import org.apache
[SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
Overview The purpose of this update is provide information on the current understanding so users are better informed when making decisions regarding risk mitigation for this issue in their environment. Work on the root cause is progressing but is still in a state of flux. Discussion is focussed on workarounds that could be applied that would allow server initiated renegotiation without exposing the participants to the vulnerability described in CVE-2009-3555. BIO Connector = The HTTP BIO connector that ships with 6.0.20 and 5.5.28 supports client and server initiated negotiation and is vulnerable to CVE-2009-3555. A patch [1],[2] has been applied to trunk, 6.0.x and 5.5.x that provides an option to disable renegotiation. This patch has an issue in that it uses an asynchronous callback to close the connection when a handshake is detected. It is theoretically possible for an attack to complete before the connection is closed. When negotiation is disabled, both server and client initiated attempts to renegotiate are logged. An updated patch [3] has been applied to trunk and proposed for 6.0.x and 5.5.x that resolves the asynchronous concerns but only logs server initiated renegotiation. Users of 6.0.20, 5.5.28 and earlier versions can apply either of the patches. It will be necessary to build Tomcat from source to use these patches. Testing with both these patches has shown that using the connector attributes clientAuth="want" and allowUnsafeLegacyRenegotiation="false" provides a similar user experience during negotiation to clientAuth="false" and allowUnsafeLegacyRenegotiation="true" although this may vary by application. It is anticipated that 6.0.21 and 5.5.29 releases will be made once the situation stabilises and the Tomcat development team is confident that further changes will not be required. [1]http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc6.patch [2]http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc5.patch [3]http://svn.apache.org/viewvc?rev=882320&view=rev NIO Connector = The HTTP NIO connector that ships with 6.0.20 does not support client or server initiated renegotiation and is therefore not vulnerable to CVE-2009-3555. As and when negotiation support is added to the NIO connector, it will support the allowUnsafeLegacyRenegotiation connector attribute and behave in a similar manner to the HTTP BIO connector. APR / native Connector == Behaviour of the APR/native connector depends on the version of the APR/native connector and on the version of OpenSSL that the connector is build with. Versions prior to APR/native 1.1.16 are not discussed. The windows binaries available from the ASF have been built with the following OpenSSL versions: APR/native OpenSSL 1.1.16 0.9.8i 1.1.17 0.9.8l 1.1.18 TBD - not yet released Any version of the APR/native connector built with OpenSSl 0.9.8l will not support client or server initiated negotiation and will, therefore, not be vulnerable to CVE-2009-3555. Client initiated negotiation is supported in 1.1.16 and 1.1.17. These versions are, therefore, vulnerable to CVE-2009-3555 unless built with OpenSSL 0.9.8l. Client initiated negotiation has been disabled in 1.1.18. Therefore, this version is not vulnerable to CVE-2009-3555 via client initiated renegotiation although it may still be vulnerable via server initiated renegotiation. Server initiated renegotiation is supported in 1.1.17 onwards. Therefore, 1.1.17 onwards is vulnerable to CVE-2009-3555 via server initiated renegotiation unless the APR/native connector is built with OpenSSL 0.9.8l. Questions / comments Any questions or comments should be directed to the Tomcat users mailing list in the first instance. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r882723 - in /tomcat/trunk/modules/jdbc-pool: ./ doc/ java/org/apache/tomcat/jdbc/pool/ java/org/apache/tomcat/jdbc/pool/jmx/
Author: fhanik
Date: Fri Nov 20 21:39:36 2009
New Revision: 882723
URL: http://svn.apache.org/viewvc?rev=882723&view=rev
Log:
Add in DataSource supprot
Add in XA support
Modified:
tomcat/trunk/modules/jdbc-pool/.classpath
tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceProxy.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PoolConfiguration.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ProxyConnection.java
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/jmx/ConnectionPool.java
Modified: tomcat/trunk/modules/jdbc-pool/.classpath
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/.classpath?rev=882723&r1=882722&r2=882723&view=diff
==
--- tomcat/trunk/modules/jdbc-pool/.classpath (original)
+++ tomcat/trunk/modules/jdbc-pool/.classpath Fri Nov 20 21:39:36 2009
@@ -7,5 +7,6 @@
+
Modified: tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml?rev=882723&r1=882722&r2=882723&view=diff
==
--- tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
+++ tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Fri Nov 20 21:39:36 2009
@@ -88,6 +88,9 @@
Get JMX notifications and log entries when connections are suspected
for being abandoned. This is similar to
the removeAbandonedTimeout but it doesn't take any
action, only reports the information.
This is achieved using the suspectTimeout
attribute.
+ Connections can be retrieved from a java.sql.Driver or
a javax.sql.DataSource
+ This is achieved using the dataSource and
dataSourceJNDI attributes.
+ XA connection support
@@ -401,6 +404,14 @@
logged and a JMX notification gets sent once.
+
+ (javax.sql.DataSource)
+
+
+
+ (String)
+
+
Modified:
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?rev=882723&r1=882722&r2=882723&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
Fri Nov 20 21:39:36 2009
@@ -277,7 +277,7 @@
}
try {
-getProxyConstructor(con.getConnection() instanceof XAConnection);
+getProxyConstructor(con.getXAConnection() != null);
//create the proxy
//TODO possible optimization, keep track if this connection was
returned properly, and don't generate a new facade
Connection connection =
(Connection)proxyClassConstructor.newInstance(new Object[] { handler });
Modified:
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java?rev=882723&r1=882722&r2=882723&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java
Fri Nov 20 21:39:36 2009
@@ -104,6 +104,10 @@
protected static final String PROP_USE_EQUALS = "useEquals";
protected static final String PROP_USE_CON_LOCK = "useLock";
+protected static final String PROP_DATASOURCE= "dataSource";
+protected static final String PROP_DATASOURCE_JNDI = "dataSourceJNDI";
+
+
public static final int UNKNOWN_TRANSACTIONISOLATION = -1;
public static final String OBJECT_NAME = "object_name";
@@ -147,7 +151,9 @@
OBJECT_NAME,
PROP_ABANDONWHENPERCENTAGEFULL,
PROP_MAXAGE,
-PROP_USE_CON_LOCK
+PROP_USE_CON_LOCK,
+PROP_DATASOURCE,
+PROP_DATASOURCE_JNDI,
};
// -- ObjectFactory Methods
@@ -425,6 +431,16 @@
poolProperties.setUseLock(Boolean.parseBoolean(value));
}
DO NOT REPLY [Bug 48253] New: Tomcat Native patch - adding dynamic locking callbacks for openssl engines
https://issues.apache.org/bugzilla/show_bug.cgi?id=48253 Summary: Tomcat Native patch - adding dynamic locking callbacks for openssl engines Product: Tomcat Native Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Library AssignedTo: dev@tomcat.apache.org ReportedBy: drugg...@primary.net Created an attachment (id=24576) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24576) Adds dynamic locking callbacks to TCNative for use by openssl engines Hello; The attached patch adds dynamic locking callbacks needed by certain engines in OpenSSL (chil, specifically). Most of this code was poached from HTTPD 2.2.x mod_ssl (ssl_util.c). The notable differences to TCNative after applying the patch are that the call to ssl_thread_setup had to be moved before the engine is initialized since the callbacks must be set before engine init, and the dynamic callback functions were added to ssl_thread_setup. The issue: When utilizing an OpenSSL engine that requires the locking callback, no locks will be found causing the vendor's native library to exit. When using chil, this only happens when an assertion fails and detects that multiple threads are active, but no upcalls are provided. I am unsure what other engines require this functionality. The solution: Add the callback functions to use APR locks. Register them with OpenSSL via the CRYPTO_set_dyn. functions. Note: This is the first TCNative patch I have submitted and was informed that there should be a xdocs/miscellaneous/changelog.xml file. This patch is against the tomcat-native-1.1.16-src.tar.gz file which does not include such a document. In any event, I think the CHANGELOG.txt entry should read: Improvement: Add dynamic locking callbacks for openssl engines (druggeri) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
