Re: Tomcat 7 - META-INF/context.xml
Filip Hanik - Dev Lists wrote: > I would like to suggest that context.xml files that are contained within > directories or WAR files do not get copied to a sub directory under > "conf" where it remains if the war file or directory is removed while > the server is shutdown. > > Copying the file META-INF/context.xml has never made much sense to me on > why that was necessary or logical, it seems as a WAR file is self > contained, and should remain so. > > what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
Filip Hanik - Dev Lists wrote: > the only downside to my suggestions above is that jdbc-pool doesn't have > much developer community around it. > the usage of it has grown, and the bug reports have been very few and no > major issues are outstanding. > unless we can build a community around it, we need to figure out what to > do with it. Hence my suggestion to use jdbc-pool as the basis for the commons-pool and commons-dbcp refactoring. Commons has the developer community jdbc-pool needs and jdbc-pool has the improvements commons-pool and commons-dbcp needs. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
If you can swing moving jdbc-pool as the next gen commons-dbcp - that would be sweet. In which case, jdbc-pool would no longer exist and we'd only be left with dbcp. Which leaves us with the tomcat 6 vs no access to JDBC4 - but some faqs can point the user on how to download the needed extra software/config. -Tim Mark Thomas wrote: Hence my suggestion to use jdbc-pool as the basis for the commons-pool and commons-dbcp refactoring. Commons has the developer community jdbc-pool needs and jdbc-pool has the improvements commons-pool and commons-dbcp needs. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPNEGO/NEGOTIATE implementation for Apache Geronimo
Hi folks, Can you please suggest if there is anyway to disable the prompt for username and password when using basic authentication?? Thanks and Regards Ashish On 11/13/09, Costin Manolache wrote: > On Fri, Nov 13, 2009 at 6:44 AM, Mark Thomas wrote: > >> Ashish Jain wrote: >> >> > 4) Does this require code changes to BasicAuthenticator >> FormAuthenticator, >> > AuthenticatorBase of tomcat. >> >> Basic and form - no. Base - maybe. >> >> > Please provide your comment and suggestions. >> >> My instinct (that may be wrong) is that you'll need a new authenticator. >> If >> you >> get this working then I'd certainly consider it for inclusion in Tomcat. >> >> > An OpenID would be nice too :-) > > Costin > > > >> Mark >> >> >> - >> 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
Re: Tomcat 7 - META-INF/context.xml
On 12/09/2009 02:57 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under "conf" where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. I thought even 6 has been inconsistent, copy in one version and don't copy in another? or did I misunderstand that? Filip Mark - 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
Re: Tomcat 7 - META-INF/context.xml
Filip Hanik - Dev Lists wrote: > On 12/09/2009 02:57 AM, Mark Thomas wrote: >> Filip Hanik - Dev Lists wrote: >> >>> I would like to suggest that context.xml files that are contained within >>> directories or WAR files do not get copied to a sub directory under >>> "conf" where it remains if the war file or directory is removed while >>> the server is shutdown. >>> >>> Copying the file META-INF/context.xml has never made much sense to me on >>> why that was necessary or logical, it seems as a WAR file is self >>> contained, and should remain so. >>> >>> what ya say? >>> >> I'd be +1 for making the extraction of META-INF/context.xml optional >> with a slight preference for the default behaviour to be consistent with >> Tomcat 6. >> > I thought even 6 has been inconsistent, copy in one version and don't > copy in another? > or did I misunderstand that? 6.0.x was inconsistent between WARs and directories. That was made consistent in 6.0.19. META-INF/context.xml in WAR files always extracts/copies META-INF/context.xml in a directory doesn't copy <6.0.19, does copy 6.0.19 onwards Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48358] New: JSP-unloading reloaded
https://issues.apache.org/bugzilla/show_bug.cgi?id=48358 Summary: JSP-unloading reloaded Product: Tomcat 7 Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: isa...@apache.org Created an attachment (id=24684) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24684) Patch including tests that fixed the problem for us. Currently Tomcat does not support unloading JSPs. When constantly changing and reloading JSP files (especially during development time) this causes the JVM to run out of memory. The patch fixes this problem by tracking the last time a JSP page was requested. Objects are destroyed if a configurable number of JSPs is live, starting with the "oldest" ones. This behaviour is deactivated by default. It must be configured explicitly. The patch comes with tests that check the added functionality. To make testing easier I added easymock as dependency to the classpath. I'd appreciate any feedback on the code changes - suggestions for improvement, potential problems with the code etc. This work was done in collaboration with some of my colleagues at work. I will forward a link to this bug entry to those involved so they can provide more information on the background of the patch if needed. On a side note: Just in case you might like to include the patch - I couldn't find a "patch intended for inclusion" check box (like the one in jira) in bugzilla - thus stating explicitly: License to ASF granted for inclusion in ASF works (as per the Apache License §5). -- 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: r888860 - in /tomcat/site/trunk: docs/security-5.html docs/security-6.html xdocs/security-5.xml xdocs/security-6.xml
Author: markt Date: Wed Dec 9 16:29:54 2009 New Revision: 60 URL: http://svn.apache.org/viewvc?rev=60&view=rev Log: Add some info on CVE-2009-3555 Modified: tomcat/site/trunk/docs/security-5.html tomcat/site/trunk/docs/security-6.html tomcat/site/trunk/xdocs/security-5.xml tomcat/site/trunk/xdocs/security-6.xml Modified: tomcat/site/trunk/docs/security-5.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?rev=60&r1=59&r2=60&view=diff == --- tomcat/site/trunk/docs/security-5.html (original) +++ tomcat/site/trunk/docs/security-5.html Wed Dec 9 16:29:54 2009 @@ -1104,6 +1104,39 @@ + + +TLS SSL Man In The Middle + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555";> + CVE-2009-3555 + + +A vulnerability exists in the TLS protocol that allows an attacker to + inject arbitrary requests into an TLS stream during renegotiation. + +The TLS implementation used by Tomcat varies with connector. The blocking + IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation + provided by the JVM. The APR/native connector uses OpenSSL. + +The BIO connector is vulnerable if the JSSE version used is vulnerable. + To workaround this until a fix is available in JSSE, a new connector + attribute allowUnsafeLegacyRenegotiation has been added to + the BIO connector. It should be set to false (the default) + to protect against this vulnerability. The attribute will be available in + Tomcat 6.0.21 onwards. + +The NIO connector is not vulnerable as it does not support + renegotiation. + +The APR/native connector is vulnerable if the OpenSSL version used is + vulnerable. Building with OpenSSL 0.9.8l will disable all renegotiation + and protect against this vulernability. + +Users should be aware that the impact of disabling renegotiation will + vary with both application and client. In some circumstances disabling + renegotiation may result in some clients being unable to access the + application. + JavaMail information disclosure http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1754";> Modified: tomcat/site/trunk/docs/security-6.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?rev=60&r1=59&r2=60&view=diff == --- tomcat/site/trunk/docs/security-6.html (original) +++ tomcat/site/trunk/docs/security-6.html Wed Dec 9 16:29:54 2009 @@ -842,7 +842,40 @@ - + + +TLS SSL Man In The Middle + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555";> + CVE-2009-3555 + + +A vulnerability exists in the TLS protocol that allows an attacker to + inject arbitrary requests into an TLS stream during renegotiation. + +The TLS implementation used by Tomcat varies with connector. The blocking + IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation + provided by the JVM. The APR/native connector uses OpenSSL. + +The BIO connector is vulnerable if the JSSE version used is vulnerable. + To workaround this until a fix is available in JSSE, a new connector + attribute allowUnsafeLegacyRenegotiation has been added to + the BIO connector. It should be set to false (the default) + to protect against this vulnerability. The attribute will be available in + Tomcat 6.0.21 onwards. + +The NIO connector is not vulnerable as it does not support + renegotiation. + +The APR/native connector is vulnerable if the OpenSSL version used is + vulnerable. Building with OpenSSL 0.9.8l will disable all renegotiation + and protect against this vulernability. + +Users should be aware that the impact of disabling renegotiation will + vary with both application and client. In some circumstances disabling + renegotiation may result in some clients being unable to access the + application. + + important: Directory traversal http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2938";> CVE-2008-2938 Modified: tomcat/site/trunk/xdocs/security-5.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-5.xml?rev=60&r1=59&r2=60&view=diff == --- tomcat/site/trunk/xdocs/security-5.xml (original) +++ tomcat/site/trunk/xdocs/security-5.xml Wed Dec 9 16:29:54 2009 @@ -504,6 +504,37 @@ + +TLS SSL Man In The Middle + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555";> + CVE-2009-3555 + +A vulnerability exists in the TLS protocol that allows an attacker to + inject arbitrary req
svn commit: r888904 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: pero Date: Wed Dec 9 18:15:08 2009 New Revision: 888904 URL: http://svn.apache.org/viewvc?rev=888904&view=rev Log: cast my vote 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=888904&r1=888903&r2=888904&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Dec 9 18:15:08 2009 @@ -459,7 +459,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47342 Fix NPE on replicated context start Patch provided by Keiichi Fujino - +1: markt + +1: markt, pero -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47453 @@ -473,7 +473,7 @@ Don't try and replicate attributes we know to be non-serializable Patch by Tim Funk http://svn.apache.org/viewvc?rev=886019&view=rev - +1: markt + +1: markt, pero -1: * Prevent lost log messages on shutdown - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 - META-INF/context.xml
On 12/09/2009 07:06 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: On 12/09/2009 02:57 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under "conf" where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. I thought even 6 has been inconsistent, copy in one version and don't copy in another? or did I misunderstand that? 6.0.x was inconsistent between WARs and directories. That was made consistent in 6.0.19. META-INF/context.xml in WAR files always extracts/copies META-INF/context.xml in a directory doesn't copy<6.0.19, does copy 6.0.19 onwards Then I suggest making everything in TC 7 consistent with directories <6.0.19 That's the whole point, it creates nothing but confusion to move the file out, since it remains there and results in a failed deployment if you remove a WAR file/directory while the server is not running Filip Mark - 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
[Tomcat Wiki] Update of "PoweredBy" by Corina Mandel
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "PoweredBy" page has been changed by Corina Mandel.
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=211&rev2=212
--
{{http://www.hahnefeld.de/images/archive/small.jpg}}
"björn hahnefeld IT TC_Framework" [[http://www.hahnefeld.de|björn hahnefeld
IT]] runs on Tomcat. It is a Framework for the ATOSS employee portal with runs
on Tomcat too. Hosting-Plans for the "björn hahnefeld IT TC_Framework" can be
booked under [[http://www.hahnefeld.de/internet-services_server.html|TomCat
Co-Location and Serverhousing]].
+ = Duramental Shop =
+ {{http://www.duramental.de/images/logo/meria.gif}}
+ "Duramental Online-Shop" [[http://www.duramental.de|DURAMENTAL Glutathion]]
runs on Tomcat and is realized on JSP-Pages. The Backend is a client solution
based on swing. A complete Java-App!
<>
== More Stuff ==
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "PoweredBy" by Corina Mandel
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "PoweredBy" page has been changed by Corina Mandel.
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=212&rev2=213
--
= Duramental Shop =
{{http://www.duramental.de/images/logo/meria.gif}}
- "Duramental Online-Shop" [[http://www.duramental.de|DURAMENTAL Glutathion]]
runs on Tomcat and is realized on JSP-Pages. The Backend is a client solution
based on swing. A complete Java-App!
+ "Duramental Online-Shop" [[http://www.duramental.de|DURAMENTAL Glutathion]]
runs on Tomcat and is realized with JSP-Pages. The Backend is a client solution
based on swing - a complete Java-App!
<>
== More Stuff ==
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPNEGO/NEGOTIATE implementation for Apache Geronimo
On Dec 9, 2009, at 5:03 AM, Ashish Jain wrote: Hi folks, Can you please suggest if there is anyway to disable the prompt for username and password when using basic authentication?? That's browser behavior, so the only thing you can do from the server side is not use plain BASIC auth. Are you using a SPNEGO enabled browser on a platform where it can recognize your (client side) kerberos login? Do you have a link to a description of how SPNEGO is supposed to work? thanks david jencks Thanks and Regards Ashish On 11/13/09, Costin Manolache wrote: On Fri, Nov 13, 2009 at 6:44 AM, Mark Thomas wrote: Ashish Jain wrote: 4) Does this require code changes to BasicAuthenticator FormAuthenticator, AuthenticatorBase of tomcat. Basic and form - no. Base - maybe. Please provide your comment and suggestions. My instinct (that may be wrong) is that you'll need a new authenticator. If you get this working then I'd certainly consider it for inclusion in Tomcat. An OpenID would be nice too :-) Costin Mark - 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #19 from jcran 2009-12-09 23:57:11 UTC --- At the risk of sounding like a troll, this is a pretty major security issue. Why is it only now being dealt with? True, it's not going prevent all session fixation, but as Mark Thomas mentioned, it goes a /long/ way, and makes it /much/ more difficult to pull off. You can no longer shoot a simple link to a user, and immediately have access to their session Regardless, it does prevent Session Hijacking - http://en.wikipedia.org/wiki/Session_hijacking - (esp. in applications that don't expire the session on the server). Imagine you visit an application at a public PC, and a session ID is written to the URL. When that page is saved to the browser's cache, the URL is saved with the JSESSIONID parameter. A user could simply browse this cache, looking for valid session ids. Similarly, the session id can be cached in a proxy cache, or be sniffed along the path. Until this is fixed, i'm recommending the following: Prevent SessionID from being written in the URL. There’s not an easy configuration option for this with Tomcat, unfortunately: http://forum.springsource.org/archive/index.php/t-27259.html Ensure a new SessionID is set when the user successfully logs into the application. This will prevent an attack called Session Fixation: http://www.acros.si/papers/session_fixation.pdf Implement relatively quick expiring sessions on the server (30 mins or less) Implement HTTPS w/ secure cookies (to prevent sidejacking - and issue that will persist regardless of session id's in the url) More info here: http://blog.0x0e.org/post/277275694/tomcats-jsessionid-in-the-url -- 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 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #20 from jcran 2009-12-09 23:59:01 UTC --- i should be careful. it doesn't prevent all session hijacking. just certain use-cases. see comments above. jcran -- 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
