DO NOT REPLY [Bug 51506] New: Support for TLS False Start
https://issues.apache.org/bugzilla/show_bug.cgi?id=51506 Bug #: 51506 Summary: Support for TLS False Start Product: Tomcat 7 Version: unspecified Platform: PC Status: NEW Severity: normal Priority: P2 Component: Connectors AssignedTo: dev@tomcat.apache.org ReportedBy: shashank.shekhar.glo...@gmail.com Classification: Unclassified https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 describes a new extension for reducing the overall roundtrip count in the TLS handshake by one. Chrome 9+ has support for it and has seen a 30% improvement in latency. Firefox has a ticket but is yet to prioritize it (https://bugzilla.mozilla.org/show_bug.cgi?id=658222). Supporting False Start from the server side will reduce the roundtrip count by one during abridged TLS handshakes. Does this involve waiting for Java's SSL implementation to add support for this kind of handshake modification as well? -- 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 51505] Blue Screen When shutdown the Tomcat Window
https://issues.apache.org/bugzilla/show_bug.cgi?id=51505 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2011-07-14 07:50:48 UTC --- If stopping a Java process crashes the OS then that is not a bug in the Java code that the JVM is running. It is most likely an OS or JVM bug that should be reported to the appropriate vendor. -- 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 51506] Support for TLS False Start
https://issues.apache.org/bugzilla/show_bug.cgi?id=51506 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID OS/Version||All --- Comment #1 from Mark Thomas 2011-07-14 07:55:01 UTC --- Tomcat does not implement SSL, it uses the JSSE implementation from the JVM and/or OpenSSL. Once those implementations support this, Tomcat will use them automatically. -- 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
[VOTE] Release Apache Tomcat 7.0.19
The proposed Apache Tomcat 7.0.19 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.19/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_19/ The proposed 7.0.19 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.19 Alpha [ ] Beta - go ahead and release as 7.0.19 Beta [ ] Stable - go ahead and release as 7.0.19 Stable Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1146623 - in /tomcat/trunk: conf/catalina.properties webapps/docs/changelog.xml
Author: kkolinko Date: Thu Jul 14 09:58:31 2011 New Revision: 1146623 URL: http://svn.apache.org/viewvc?rev=1146623&view=rev Log: Corrected typo in the value of tomcat.util.scan.DefaultJarScanner.jarsToSkip property Modified: tomcat/trunk/conf/catalina.properties tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/conf/catalina.properties URL: http://svn.apache.org/viewvc/tomcat/trunk/conf/catalina.properties?rev=1146623&r1=1146622&r2=1146623&view=diff == --- tomcat/trunk/conf/catalina.properties (original) +++ tomcat/trunk/conf/catalina.properties Thu Jul 14 09:58:31 2011 @@ -93,7 +93,7 @@ jasper.jar,jasper-el.jar,ecj-*.jar,\ tomcat-api.jar,tomcat-util.jar,tomcat-coyote.jar,tomcat-dbcp.jar,\ tomcat-i18n-en.jar,tomcat-i18n-es.jar,tomcat-i18n-fr.jar,tomcat-i18n-ja.jar,\ tomcat-juli-adapters.jar,catalina-jmx-remote.jar,catalina-ws.jar,\ -tomcat-jdbc.jar\ +tomcat-jdbc.jar,\ commons-beanutils*.jar,commons-codec*.jar,commons-collections*.jar,\ commons-dbcp*.jar,commons-digester*.jar,commons-fileupload*.jar,\ commons-httpclient*.jar,commons-io*.jar,commons-lang*.jar,commons-logging*.jar,\ Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1146623&r1=1146622&r2=1146623&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Thu Jul 14 09:58:31 2011 @@ -53,6 +53,18 @@ They eventually become mixed with the numbered issues. (I.e., numbered issues to not "pop up" wrt. others). --> + + + + +Corrected missing comma in the value of jarsToSkip +property in conf/catalina.properties file, which +caused tomcat-jdbc.jar and commons-beanutils*.jar to be not +ignored when scanning jars for tag libraries. (kkolinko) + + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1146627 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kfujino Date: Thu Jul 14 10:02:00 2011 New Revision: 1146627 URL: http://svn.apache.org/viewvc?rev=1146627&view=rev Log: votes 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=1146627&r1=1146626&r2=1146627&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jul 14 10:02:00 2011 @@ -189,14 +189,14 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=1095138&view=rev It is used in TC7 since 7.0.14 Changelog: http://commons.apache.org/pool/changes-report.html - +1: kkolinko, markt + +1: kkolinko, markt, kfujino -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51473 Fix concatenation of values in SecurityConfig.setSecurityProperty() when the value provided by JRE is null. http://svn.apache.org/viewvc?rev=1142904&view=rev - +1: kkolinko, markt + +1: kkolinko, markt, kfujino -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51324 @@ -204,7 +204,7 @@ PATCHES PROPOSED TO BACKPORT: ensure that the doFlush flag does not get stuck in the enabled state. Patch by Jeremy Norris. http://svn.apache.org/viewvc?rev=1133014&view=rev - +1: kkolinko, markt + +1: kkolinko, markt, kfujino -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51475 @@ -212,7 +212,7 @@ PATCHES PROPOSED TO BACKPORT: Based on a patch by Christian Stöber http://svn.apache.org/viewvc?rev=1143134&view=rev (GzipInterceptor.java only) http://svn.apache.org/viewvc?rev=1143150&view=rev - +1: markt, kkolinko + +1: markt, kkolinko, kfujino -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46252 @@ -230,12 +230,12 @@ PATCHES PROPOSED TO BACKPORT: and also fix wrong mapping for "enabled" property - it is getEnabled(). https://issues.apache.org/bugzilla/attachment.cgi?id=27279 https://issues.apache.org/bugzilla/attachment.cgi?id=27280 (JMX) - +1: kkolinko, markt + +1: kkolinko, markt, kfujino -1: * Fix various sendfile issues. CVE-2011-2526 This is a port of r1145380, r1145383, r1145489, r1145571, r1145694 and r1146005 http://people.apache.org/~markt/patches/2011-07-13-cve-2011-2526-tc6.patch - +1: markt, jfclere + +1: markt, jfclere, kfujino -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1146623 - in /tomcat/trunk: conf/catalina.properties webapps/docs/changelog.xml
2011/7/14 : > Author: kkolinko > Date: Thu Jul 14 09:58:31 2011 > New Revision: 1146623 > > URL: http://svn.apache.org/viewvc?rev=1146623&view=rev > Log: > Corrected typo in the value of tomcat.util.scan.DefaultJarScanner.jarsToSkip > property > > Modified: > tomcat/trunk/conf/catalina.properties > tomcat/trunk/webapps/docs/changelog.xml > > tomcat-api.jar,tomcat-util.jar,tomcat-coyote.jar,tomcat-dbcp.jar,\ > tomcat-i18n-en.jar,tomcat-i18n-es.jar,tomcat-i18n-fr.jar,tomcat-i18n-ja.jar,\ > tomcat-juli-adapters.jar,catalina-jmx-remote.jar,catalina-ws.jar,\ > -tomcat-jdbc.jar\ > +tomcat-jdbc.jar,\ > commons-beanutils*.jar,commons-codec*.jar,commons-collections*.jar,\ > commons-dbcp*.jar,commons-digester*.jar,commons-fileupload*.jar,\ > commons-httpclient*.jar,commons-io*.jar,commons-lang*.jar,commons-logging*.jar,\ It would be nice to add a Test to our testsuite to test that any ".jar" in this property value is followed by comma: either by (optional spaces and comma) or by (end of line). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51507] New: NumberFormatNotFoundException:null
https://issues.apache.org/bugzilla/show_bug.cgi?id=51507
Bug #: 51507
Summary: NumberFormatNotFoundException:null
Product: Tomcat 6
Version: 6.0.32
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: venkatcse...@gmail.com
Classification: Unclassified
Created attachment 27284
--> https://issues.apache.org/bugzilla/attachment.cgi?id=27284
the bug is present n this java application
when i try to execute a servlet on tomcat it gives this error
my servlet code is:
import javax.servlet.*;
import java.io.*;
public class AdditionServlet extends GenericServlet
{
public void service(ServletRequest request,ServletResponse response)
{
try
{
String a=request.getParameter("t1");
String b=request.getParameter("t2");
int n1=Integer.parseInt(a);
int n2=Integer.parseInt(b);
int sum=n1+n2;
response.setContentType("text/html");
PrintWriter out=response.getWriter();
out.println("");
out.println("the sum of the two numbers is: "+sum+"");
out.println("");
out.close();}
catch(NumberFormatException e)
{
System.out.println(e);
}
catch(IOException e)
{
System.out.println(e);
}
}
}
--
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 51507] NumberFormatNotFoundException:null
https://issues.apache.org/bugzilla/show_bug.cgi?id=51507 Tim Funk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID OS/Version||All --- Comment #1 from Tim Funk 2011-07-14 10:48:25 UTC --- http://tomcat.apache.org/bugreport.html#Bugzilla_is_not_a_support_forum Please use the user list. -- 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 51508] New: Using generic URL in jsp-config breaks welcome file handling
https://issues.apache.org/bugzilla/show_bug.cgi?id=51508 Bug #: 51508 Summary: Using generic URL in jsp-config breaks welcome file handling 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: knst.koli...@gmail.com Classification: Unclassified Using 7.0.19 release candidate Steps to reproduce: 1. Go to webapps/examples/WEB-INF/web.xml, find existing element in the file, add the following text at the end of that element: /* true 2. Clear work directory. Start Tomcat. 3. Navigate to http://localhost:8080/examples/jsp Expected result: list of examples, jsp/index.html Actual result: Error 500 page org.apache.jasper.JasperException: File "/jsp" not found org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116) org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:678) org.apache.jasper.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:109) org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:337) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:190) org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:119) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:193) org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:644) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) Additional notes: -- 1. The following URLs for the same page do work: http://localhost:8080/examples/jsp/ http://localhost:8080/examples/jsp/index.html The following URL does not work: http://localhost:8080/examples/jsp So it seems that it is redirection from http://localhost:8080/examples/jsp -> http://localhost:8080/examples/jsp/ that breaks. 2. Calling a JSP page directly does work, http://localhost:8080/examples/jsp/jsp2/tagfiles/hello.jsp -- 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: r1146703 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/connector/ java/org/apache/catalina/servlets/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
Author: markt
Date: Thu Jul 14 13:38:40 2011
New Revision: 1146703
URL: http://svn.apache.org/viewvc?rev=1146703&view=rev
Log:
Fix various sendfile issues.
This fixes CVE-2011-2526
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/LocalStrings.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/LocalStrings.properties
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1146703&r1=1146702&r2=1146703&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jul 14 13:38:40 2011
@@ -232,10 +232,3 @@ PATCHES PROPOSED TO BACKPORT:
https://issues.apache.org/bugzilla/attachment.cgi?id=27280 (JMX)
+1: kkolinko, markt, kfujino
-1:
-
-* Fix various sendfile issues. CVE-2011-2526
- This is a port of r1145380, r1145383, r1145489, r1145571, r1145694 and
- r1146005
- http://people.apache.org/~markt/patches/2011-07-13-cve-2011-2526-tc6.patch
- +1: markt, jfclere, kfujino
- -1:
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/LocalStrings.properties?rev=1146703&r1=1146702&r2=1146703&view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/LocalStrings.properties
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/LocalStrings.properties
Thu Jul 14 13:38:40 2011
@@ -62,6 +62,7 @@ coyoteRequest.parseParameters=Exception
coyoteRequest.postTooLarge=Parameters were not parsed because the size of the
posted data was too big. Use the maxPostSize attribute of the connector to
resolve this if the application should accept large POSTs.
coyoteRequest.chunkedPostTooLarge=Parameters were not parsed because the size
of the posted data was too big. Because this request was a chunked request, it
could not be processed further. Use the maxPostSize attribute of the connector
to resolve this if the application should accept large POSTs.
coyoteRequest.sessionEndAccessFail=Exception triggered ending access to
session while recycling request
+coyoteRequest.sendfileNotCanonical=Unable to determine canonical name of file
[{0}] specified for use with sendfile
requestFacade.nullRequest=The request object has been recycled and is no
longer associated with this facade
Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java?rev=1146703&r1=1146702&r2=1146703&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java Thu
Jul 14 13:38:40 2011
@@ -19,6 +19,7 @@
package org.apache.catalina.connector;
+import java.io.File;
import java.io.InputStream;
import java.io.IOException;
import java.io.BufferedReader;
@@ -1455,6 +1456,26 @@ public class Request
return;
}
+// Do the security check before any updates are made
+if (Globals.IS_SECURITY_ENABLED &&
+name.equals("org.apache.tomcat.sendfile.filename")) {
+// Use the canonical file name to avoid any possible symlink and
+// relative path issues
+String canonicalPath;
+try {
+canonicalPath = new File(value.toString()).getCanonicalPath();
+} catch (IOException e) {
+throw new SecurityException(sm.getString(
+"coyoteRequest.sendfileNotCanonical", value), e);
+}
+// Sendfile is performed in Tomcat's security context so need to
+// check if the web app is permitted to access the file while still
+// in the web app's security context
+System.getSecurityManager().checkRead(canonicalPath);
+// Update the value so the canonical path is used
+value = canonicalPath;
+}
+
oldValue = attributes.put(name, value);
if (oldValue != null) {
replaced = true;
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
URL:
http://svn.apache.org/vi
svn commit: r1146707 - in /tomcat/site/trunk: docs/security-6.html xdocs/security-6.xml
Author: markt Date: Thu Jul 14 13:41:49 2011 New Revision: 1146707 URL: http://svn.apache.org/viewvc?rev=1146707&view=rev Log: Update now patch has been applied Modified: tomcat/site/trunk/docs/security-6.html tomcat/site/trunk/xdocs/security-6.xml Modified: tomcat/site/trunk/docs/security-6.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?rev=1146707&r1=1146706&r2=1146707&view=diff == --- tomcat/site/trunk/docs/security-6.html (original) +++ tomcat/site/trunk/docs/security-6.html Thu Jul 14 13:41:49 2011 @@ -215,9 +215,6 @@ Apache Tomcat 6.x vulnerabilities -To be fixed in Apache Tomcat 6.0.33 (not yet released) - - Fixed in Apache Tomcat 6.0.33 (not yet released) @@ -316,11 +313,11 @@ - + - -To be fixed in Apache Tomcat 6.0.33 (not yet released) + +Fixed in Apache Tomcat 6.0.33 (not yet released) @@ -332,6 +329,29 @@ Low: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2204"; rel="nofollow">CVE-2011-2204 + + +When using the MemoryUserDatabase (based on tomcat-users.xml) and + creating users via JMX, an exception during the user creation process may + trigger an error message in the JMX client that includes the user's + password. This error message is also written to the Tomcat logs. User + passwords are visible to administrators with JMX access and/or + administrators with read access to the tomcat-users.xml file. Users that + do not have these permissions but are able to read log files may be able + to discover a user's password. + +This was fixed in + http://svn.apache.org/viewvc?rev=1140071&view=rev";> + revision 1140071. + +This was identified by Polina Genova on 14 June 2011 and + made public on 27 June 2011. + +Affects: 6.0.0-6.0.32 + + +Low: Information disclosure http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2526"; rel="nofollow">CVE-2011-2526 @@ -358,8 +378,9 @@ -There is a http://people.apache.org/~markt/patches/2011-07-13-cve-2011-2526-tc6.patch";> - proposed patch for this issue. +This was fixed in + http://svn.apache.org/viewvc?rev=1146703&view=rev";> + revision 1146703. This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011. @@ -380,57 +401,6 @@ - - - - -Fixed in Apache Tomcat 6.0.33 (not yet released) - - - - - - - - - - -Low: Information disclosure - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2204"; rel="nofollow">CVE-2011-2204 - - -When using the MemoryUserDatabase (based on tomcat-users.xml) and - creating users via JMX, an exception during the user creation process may - trigger an error message in the JMX client that includes the user's - password. This error message is also written to the Tomcat logs. User - passwords are visible to administrators with JMX access and/or - administrators with read access to the tomcat-users.xml file. Users that - do not have these permissions but are able to read log files may be able - to discover a user's password. - -This was fixed in - http://svn.apache.org/viewvc?rev=1140071&view=rev";> - revision 1140071. - -This was identified by Polina Genova on 14 June 2011 and - made public on 27 June 2011. - -Affects: 6.0.0-6.0.32 - - - - - - - - - - - - - - - Modified: tomcat/site/trunk/xdocs/security-6.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-6.xml?rev=1146707&r1=1146706&r2=1146707&view=diff == --- tomcat/site/trunk/xdocs/security-6.xml (original) +++ tomcat/site/trunk/xdocs/security-6.xml Thu Jul 14 13:41:49 2011 @@ -30,9 +30,31 @@ - + Low: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2204"; + rel="nofollow">CVE-2011-2204 + +When using the MemoryUserDatabase (based on tomcat-users.xml) and + creating users via JMX, an exception during the user creation process may + trigger an error message in the JMX client that includes the user's + password. This error message is also written to the Tomcat logs. User + passwords are visible to administrators with JMX access and/or + administrators with read access to the tomcat-users.xml file. Users that + do not have these permissions but are able to read log files may be able + to discover a user's password. + +This was fixed in + http://svn.apache.org/viewvc?rev=1140071&view=rev";> + revision 1140071. + +This was identified by Polina Genova on 14 June 2011 and + made public on 27 June 2011. + +Affects: 6.0.0-6.0.32 + +Low: Information disclosure http:/
Casual proposal for change to WebappClassLoader.clearReferencesThreads
All, Is there any interest in having a configuration option for WCL that allows certain thread names to be ignored during webapp shutdown? See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. It appears that there may sometimes be a race condition where the webapp can't force the termination of an app-started thread that *will* eventually shut down. A minor change could alleviate printing a warning message on redeploy that may worry admins. I'm sure this would be useful to Terence, but I'm not sure if there's wide applicability. Any thoughts? -chris signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 51509] New: Csrf Prevention Filter`s LruCache is not thread save
https://issues.apache.org/bugzilla/show_bug.cgi?id=51509 Bug #: 51509 Summary: Csrf Prevention Filter`s LruCache is not thread save Product: Tomcat 6 Version: 6.0.32 Platform: PC Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: ralph.apa...@humanfork.de Classification: Unclassified The LruCache (org.apache.catalina.filters.CsrfPreventionFilter$LruCache) use by Csrf Prevention Filter is base on LinkedHashMap. >From the LinkedHashMap Java Doc: Note that this implementation is not synchronized. If multiple threads access a linked hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. ... But the LruCache implementation does not synchronize the access to the map. -- 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: Casual proposal for change to WebappClassLoader.clearReferencesThreads
On 14/07/2011 15:23, Christopher Schultz wrote: > All, > > Is there any interest in having a configuration option for WCL that > allows certain thread names to be ignored during webapp shutdown? > > See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. > > It appears that there may sometimes be a race condition where the webapp > can't force the termination of an app-started thread that *will* > eventually shut down. A minor change could alleviate printing a warning > message on redeploy that may worry admins. > > I'm sure this would be useful to Terence, but I'm not sure if there's > wide applicability. Why does this help? AFAICS he's not stopped the thread, he's just stopped the scheduler. If he wants the thread to stop he'll have to hit .cancel() on the task. p > Any thoughts? > > -chris > signature.asc Description: OpenPGP digital signature
Re: Casual proposal for change to WebappClassLoader.clearReferencesThreads
On 14/07/2011 16:11, Pid wrote: > On 14/07/2011 15:23, Christopher Schultz wrote: >> All, >> >> Is there any interest in having a configuration option for WCL that >> allows certain thread names to be ignored during webapp shutdown? >> >> See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. >> >> It appears that there may sometimes be a race condition where the webapp >> can't force the termination of an app-started thread that *will* >> eventually shut down. A minor change could alleviate printing a warning >> message on redeploy that may worry admins. >> >> I'm sure this would be useful to Terence, but I'm not sure if there's >> wide applicability. > > Why does this help? AFAICS he's not stopped the thread, he's just > stopped the scheduler. If he wants the thread to stop he'll have to hit > .cancel() on the task. Actually, that might not be true. (Teach me to skim the docs). The OP is really reporting that the timer.cancel() method doesn't block & wait for all the running timer task threads to finish. Interrupting a timer task thread might not be possible without jumping through hoops; the OP reports that if the run method is empty, there's no problem - but this would be expected because the run() cycle would be short & therefore the timer task thread will win the race between contextDestroyed completing & the thread finishing. If the thread takes longer (the OP reports ~0.5s) then contextDestroyed() wins and Tomcat reports threads down. Quartz suffers from the same problem (or did last time I looked). p signature.asc Description: OpenPGP digital signature
Re: Casual proposal for change to WebappClassLoader.clearReferencesThreads
2011/7/14 Christopher Schultz : > Is there any interest in having a configuration option for WCL that > allows certain thread names to be ignored during webapp shutdown? > > See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. > > It appears that there may sometimes be a race condition where the webapp > can't force the termination of an app-started thread that *will* > eventually shut down. When webapp is stopped, its classloader is stopped as well. Allowing a thread to run will allow application to hit this absence of classloader. If application is well behaving by itself (and it is up to you to define what is well behaving) you can turn off this cleanup. What matters is whether there are leaks in the end or not. If there are none, just turn off this cleanup. It was not intended to be a panacea but just some crutches until webapps learn how to take care of the problem by themselves. I think there is no need for this option that you are suggesting. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51453] Requests to open URL that include an Authorization header do not reach servlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=51453 --- Comment #4 from Sudarsha Wijenayake 2011-07-14 15:44:50 UTC --- (In reply to comment #3) > This has been fixed in 7.0.x and will be included in 7.0.17 onwards. Is this fix now available in the following SVN path? http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_17/ I would like to give it a try before 7.0.17 goes out. 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 51453] Requests to open URL that include an Authorization header do not reach servlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=51453 --- Comment #5 from Mark Thomas 2011-07-14 15:47:46 UTC --- The 7.0.17 was stopped, as was 7.0.18. 7.0.19 in currently in progress. You can build it from the tag or from http://people.apache.org/~markt/dev/tomcat-7/ WARNING: This is NOT an official ASF release. It is a release candidate for testing purposes only. -- 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 51506] Support for TLS False Start
https://issues.apache.org/bugzilla/show_bug.cgi?id=51506 --- Comment #2 from Shashank Shekhar 2011-07-14 17:57:03 UTC --- Thanks for the clarification. I had a hunch, but it's good to see it getting answered authoritatively. -- 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: Casual proposal for change to WebappClassLoader.clearReferencesThreads
Pid, On 7/14/2011 11:25 AM, Pid wrote: > On 14/07/2011 16:11, Pid wrote: >> On 14/07/2011 15:23, Christopher Schultz wrote: >>> All, >>> >>> Is there any interest in having a configuration option for WCL that >>> allows certain thread names to be ignored during webapp shutdown? >>> >>> See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. >>> >>> It appears that there may sometimes be a race condition where the webapp >>> can't force the termination of an app-started thread that *will* >>> eventually shut down. A minor change could alleviate printing a warning >>> message on redeploy that may worry admins. >>> >>> I'm sure this would be useful to Terence, but I'm not sure if there's >>> wide applicability. >> >> Why does this help? AFAICS he's not stopped the thread, he's just >> stopped the scheduler. If he wants the thread to stop he'll have to hit >> .cancel() on the task. > > Actually, that might not be true. (Teach me to skim the docs). > > > The OP is really reporting that the timer.cancel() method doesn't block > & wait for all the running timer task threads to finish. He's properly shutting-down the task scheduling service and all the tasks finish before his code continues. The problem is a race condition between the termination of the worker threads and the thread-checking code in Tomcat. > Interrupting a timer task thread might not be possible without jumping > through hoops; the OP reports that if the run method is empty, there's > no problem - but this would be expected because the run() cycle would be > short & therefore the timer task thread will win the race between > contextDestroyed completing & the thread finishing. I thought he said that, with an empty run method, he still needs to call sleep() in order to avoid the race condition. > If the thread takes longer (the OP reports ~0.5s) then > contextDestroyed() wins and Tomcat reports threads down. > > Quartz suffers from the same problem (or did last time I looked). The problem is that the OP can't get ahold of the Thread objects themselves in order to do a join() on them. All tasks are cancelled, successfully. His hands are tied by the API. I'm trying to avoid the following progression: 1. TaskScheduler has a race condition, triggers a false alarm in Tomcat 2. IT staff, etc. are directed to ignore Tomcat warnings about threads 3. Tomcat starts reporting legitimate thread problems 4. Everyone ignores them because they have been directed to do so My proposal is to be able to identify which threads have been determined to be non-threatening, and suppress the warning. -chris signature.asc Description: OpenPGP digital signature
Re: Casual proposal for change to WebappClassLoader.clearReferencesThreads
Konstantin, On 7/14/2011 11:37 AM, Konstantin Kolinko wrote: > If application is well behaving by itself (and it is up to you to > define what is well behaving) you can turn off this cleanup. > > What matters is whether there are leaks in the end or not. If there > are none, just turn off this cleanup. It was not intended to be a > panacea but just some crutches until webapps learn how to take care of > the problem by themselves. > > I think there is no need for this option that you are suggesting. Fair enough. Consider the proposal withdrawn. -chris signature.asc Description: OpenPGP digital signature
Tomcat 7 under Java 7
Hi guys, I conducted some tests with Tomcat 7 (7.0.19) and I noticed a slower startup time under Java 7 (OpenJDK) than under Java 1.6. I also see a serious boost in startup between TC 6.0.32 and TC 7.0.19, Jetty is not too far behind. I blogged about here : http://blog.hgomez.net/2011/07/15/servlet-containers-startup-time/ If you need help to investigate speed diff between JDK 6 and 7, I'm willing to help. Regards - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
