Re: Spam vulnerability at apache
OK. Thanks guys! There is also the issue of getting spam directly to my email address, due to the fact that the email address is out there on the net in some list archives somewhere, vulnerable to email-address spiders looking for someone to point their spam cannons at. The careful ones, i.e. www.mail-archive.com, hide them, but others (marc.theaimsgroup.com) don't. Adam On 04/13/2004 11:27 PM Craig McClanahan wrote: Adam Hardy wrote: Actually I have found the spam resulting from this list to be negligible. That includes the user list. For that, you should thank the moderators of these two lists (Remy, Ignacio, Yoav, and Mark) who patiently field all the spam from non-subscribed addresses and filter out the non-relevant stuff. I'm a moderator on some other Apache lists and get tens to low hundreds of moderate requests per day; I would imagine that the Tomcat lists attract quite a few more than that. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spam vulnerability at apache (was: Re: Photo document [TID#4977])
Actually I have found the spam resulting from this list to be negligible. That includes the user list. On 04/13/2004 06:13 PM Jeff Tulley wrote: If I am not mistaken, this email probably results from somebody on the list having one of the many recent viruses. An email is being sent from somebody's computer, with the From or Reply-to being tomcat-dev, and the To being the Russian place. The russian site has an auto-responder, and so it sends back an email to the list.Yes, this is a mail software problem in that the russian place was automatically subscribed earlier probably from a similar virus email with a reply-to being something like tomcat-dev-subscribe at jakarta The point is that nobody necessarily has your address. But, being on such a large public list, you definitely put yourself at risk at getting more virus and spam emails. If this concerns you greatly, I'd advise getting a secondary, junk email account for posts to this list, one that you could kill someday and be done with any spam or virus mails brought to you by participation here. I myself wish I had done so. (probably too late to do much good now!) [EMAIL PROTECTED] 4/12/04 9:20:31 PM Hi, I extremely apologize for this message, but i think this needs to be figured out. I just yesterday registered my new email address with tomcat-dev, and i received the spam below almost immediately thereafter. Only a few people are aware of this email address, so the origin of spam info 99% appears to be tomcat-dev registration. Is there any chance that DNS gets resolved to one of several IPs, one of which collects these emails and uses them for spam (or perhaps is infected with a virus)? I would look for any IPs based in russia as the prime suspects, because this email contains russian text and appears to be originated there. What's worse is that 25 minutes after this spam, i received another one of similar content. Please help save me and others from this plague of the Internet. I entrusted apache.org with this address, and hope we can keep it between us. P.S. If there are other people who received similar emails, please let me, the admins, or the list know. If you let only me know, i will accumulate the number of people affected and forward this to an admin. P.P.S. I see that emails are protected in the archives publicly published, and i think this issue is in the same category. Thanks, rsa/ [EMAIL PROTECTED] wrote: russian(win-1251): ! ?? ??? ? ??? ? ? ?? ?? ?? Photo document, ??? . ??? ?? ?? . ?? ? ??, ? ??? ? [TID#4977]. ??, ? ? : [TID#4977] ? ? (subject) ??? ??? ?? ??? . ??? ? ??? ??? ?? ??? ?? (reply). C ?, ?? ??? ? ??? ?-10 http://www.m-10.ru english: Greetings, This message has been automatically generated in response to your message regarding Photo document, the content of which appears below. There is no need to reply to it now. Support has received your message and it has been assigned a ticket ID of [TID#4977]. Please include the string: [TID#4977] in the subject line of all future correspondence about this problem. To do so, you may reply to this message. WBR, Support Team Hosting Operator M-10 http://www.m-10.ru Original Message- Please, photo document. Yours sincerely +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new F-Secure OnlineAntiVirus +++ Visit us: www.f-secure.com -Headers Follow-- Received: from [EMAIL PROTECTED] by office.m-10.ru (CommuniGate Pro GROUP 4.1.8) with GROUP id 1745058; Mon, 12 Apr 2004 17:13:05 +0400 Received: from [62.5.188.222] (HELO office.m-10.ru) by office.m-10.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1745042 for [EMAIL PROTECTED]; Mon, 12 Apr 2004 17:12:58 +0400 X-Antivirus: Checked by Dr.Web (http://www.drweb.net) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Photo document Date: Mon, 12 Apr 2004 17:11:48 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0016=_NextPart_000_0016 X-Priority: 3 X-Msmail-Priority: Normal Message-Id: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
Re: deployment problems moving from tomcat 5.0.18 to 5.0.19
Looks like it's something to do with the xml parser. Is it a standard install of tomcat 5? Have you included a xerces jar with your webapp? Also put your context in a my-context-name.xml file in conf/Catalina/localhost Adam On 04/05/2004 08:58 AM Matt Smith wrote: Actually this is a problem between 5.0.18 and 5.0.19. The same context descriptor deploys successfully on 5.0.18, but the errors below show up on 5.0.19. Any ideas on what changed between the two releases that would cause this? Thanks, m. -Original Message- From: Matt Smith [mailto:[EMAIL PROTECTED] Sent: Monday, April 05, 2004 12:33 AM To: [EMAIL PROTECTED] Subject: deployment problems moving from tomcat 4.1.30 to 5.0.19 I am migrating from Tomcat 4.1.30 to 5.0.19 and have been experiencing problems with deployment. The context descriptor below works fine for deployment on Tomcat 4.1.30, but when I try to use it on 5.0.19, all I get is the following in localhost_log 2004-04-05 00:22:54 StandardHost[localhost]: Error deploying application at context path null java.lang.NullPointerException at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 40) at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 66) at org.apache.commons.digester.Digester.endElement(Digester.java:1061) at org.apache.catalina.util.CatalinaDigester.endElement(CatalinaDigester.ja va:123) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unk nown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis patcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1567) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeploy er.java:519) at org.apache.catalina.core.StandardHost.install(StandardHost.java:906) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java :527) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1008) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:39 4) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu pport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1134) at org.apache.catalina.core.StandardHost.start(StandardHost.java:832) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1126) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:521) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2345) at org.apache.catalina.startup.Catalina.start(Catalina.java:594) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:398) and : Using CATALINA_BASE: c:\work\sandbox\views\matt-calvert-tip-20031223142431\pro d\build Using CATALINA_HOME: c:\work\sandbox\tools\tomcat-5.0.19 Using CATALINA_TMPDIR: c:\work\sandbox\views\matt-calvert-tip-20031223142431\pro d\build\temp Using JAVA_HOME: c:\work\sandbox\tools\java-1.4.2_04 Apr 5, 2004 12:26:06 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Apr 5, 2004 12:26:06 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1578 ms Apr 5, 2004 12:26:06 AM org.apache.catalina.mbeans.GlobalResourcesLifecycleListe ner createMBeans SEVERE: Creating Role MBean for role role rolename=tomcat/ Apr 5, 2004 12:26:06 AM org.apache.catalina.mbeans.GlobalResourcesLifecycleListe ner createMBeans SEVERE: Creating Role MBean for role role rolename=role1/ Apr 5, 2004 12:26:06 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Apr 5, 2004 12:26:06 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.0.19 Apr 5, 2004 12:26:06 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled Apr 5, 2004 12:26:06 AM org.apache.catalina.core.StandardHost getDeployer INFO: Create Host deployer for direct deployment ( non-jmx ) Apr 5, 2004 12:26:06 AM org.apache.catalina.core.StandardHostDeployer install
Re: container managed security
I searched for some time in various archives, bug databases, mailing lists etc trying to find this information but my searching basically always brings me back to here. All I want to do is set up container managed security to allow unencrypted sessions on protected resources, along with an SSL-based non-clear text form-based login. I discussed this partly with different people at different times but was not involved (or paying attention would be a better way to put it) when the servlet spec gurus and followers discussed the issue, and subsequently I have unanswered questions about the implementation of changes (in tomcat) that leave my requirement unattainable (almost). I have scoured the mailing list archives, google and sun for relevant info, but haven't found anything, even though that is the place to which people constantly refer me. I know this is old ground but I need to get the low-down on it. Thanks in advance for any tips, links, pointers or explanations! Adam On 03/12/2004 06:46 PM Adam Hardy wrote: In tomcat 4 I was able to to protect my app with non-SSL security-constraints while using SSL form-based authentication so that the passwords were not sent in clear text. This has been a specification of the last 3 projects I have worked on. In tomcat 5 this is impossible without coding a work-around. I logged this as a bug in tomcat but it was closed as 'invalid'. http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 I remember 6 months ago someone saying that the tomcat developers had decided that due to the danger of session-hijacking, if it was worth encrypting the login, it was worth encrypting the whole session traffic. Due to the charges that the extra hardware brings when doing all logged-in sessions in SSL, amongst other reasons, I disagreed and developed a work-around to let me carry on using the Struts Tomcat security features. This took me a few days back then, and then this week something else cropped up which caused me to revisit the work-around code and spend 2 days adding to it (and documenting it - it's pretty arcane). It occurred to me that this will always happen. The work-around is vulnerable to any changes in the servlet spec of course, but also in tomcat and in struts. I would appreciate finding out the whole story on this - last time I just let it go through lack of time. If I'm in the wrong place - perhaps the JCP Servlet working group would be better - can someone point me in the right direction? Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: container managed security]
Is there any way of seeing how the servlet spec team reached their decisions, apart from sending an email to the address mentioned in the spec? (I've done that before without any result). Is there a mailing list for it? Looking around at java.sun.com doesn't bring much to light. Thanks Adam On 03/18/2004 09:38 PM Mark Thomas wrote: Adam, I thought that this was a spec issue and a quick review of the bugzilla postings confirms this. The best place to follow this up is with the servlet spec team. Mark -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Thursday, March 18, 2004 10:46 AM To: [EMAIL PROTECTED] Subject: [Fwd: container managed security] Nobody responded to my previous message, but I am still searching for information on the subject. Any references to docs would be welcome. I have searched for threads on this list in the archives but had no joy either. Thanks Adam Original Message From: - Fri Mar 12 18:50:10 2004 To: [EMAIL PROTECTED] Subject: container managed security In tomcat 4 I was able to to protect my app with non-SSL security-constraints while using SSL form-based authentication so that the passwords were not sent in clear text. This has been a specification of the last 3 projects I have worked on. In tomcat 5 this is impossible without coding a work-around. I logged this as a bug in tomcat but it was closed as 'invalid'. http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 I remember 6 months ago someone saying that the tomcat developers had decided that due to the danger of session-hijacking, if it was worth encrypting the login, it was worth encrypting the whole session traffic. Due to the charges that the extra hardware brings when doing all logged-in sessions in SSL, amongst other reasons, I disagreed and developed a work-around to let me carry on using the Struts Tomcat security features. This took me a few days back then, and then this week something else cropped up which caused me to revisit the work-around code and spend 2 days adding to it (and documenting it - it's pretty arcane). It occurred to me that this will always happen. The work-around is vulnerable to any changes in the servlet spec of course, but also in tomcat and in struts. I would appreciate finding out the whole story on this - last time I just let it go through lack of time. If I'm in the wrong place - perhaps the JCP Servlet working group would be better - can someone point me in the right direction? Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: container managed security]
Nobody responded to my previous message, but I am still searching for information on the subject. Any references to docs would be welcome. I have searched for threads on this list in the archives but had no joy either. Thanks Adam Original Message From: - Fri Mar 12 18:50:10 2004 To: [EMAIL PROTECTED] Subject: container managed security In tomcat 4 I was able to to protect my app with non-SSL security-constraints while using SSL form-based authentication so that the passwords were not sent in clear text. This has been a specification of the last 3 projects I have worked on. In tomcat 5 this is impossible without coding a work-around. I logged this as a bug in tomcat but it was closed as 'invalid'. http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 I remember 6 months ago someone saying that the tomcat developers had decided that due to the danger of session-hijacking, if it was worth encrypting the login, it was worth encrypting the whole session traffic. Due to the charges that the extra hardware brings when doing all logged-in sessions in SSL, amongst other reasons, I disagreed and developed a work-around to let me carry on using the Struts Tomcat security features. This took me a few days back then, and then this week something else cropped up which caused me to revisit the work-around code and spend 2 days adding to it (and documenting it - it's pretty arcane). It occurred to me that this will always happen. The work-around is vulnerable to any changes in the servlet spec of course, but also in tomcat and in struts. I would appreciate finding out the whole story on this - last time I just let it go through lack of time. If I'm in the wrong place - perhaps the JCP Servlet working group would be better - can someone point me in the right direction? Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
container managed security
In tomcat 4 I was able to to protect my app with non-SSL security-constraints while using SSL form-based authentication so that the passwords were not sent in clear text. This has been a specification of the last 3 projects I have worked on. In tomcat 5 this is impossible without coding a work-around. I logged this as a bug in tomcat but it was closed as 'invalid'. http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 I remember 6 months ago someone saying that the tomcat developers had decided that due to the danger of session-hijacking, if it was worth encrypting the login, it was worth encrypting the whole session traffic. Due to the charges that the extra hardware brings when doing all logged-in sessions in SSL, amongst other reasons, I disagreed and developed a work-around to let me carry on using the Struts Tomcat security features. This took me a few days back then, and then this week something else cropped up which caused me to revisit the work-around code and spend 2 days adding to it (and documenting it - it's pretty arcane). It occurred to me that this will always happen. The work-around is vulnerable to any changes in the servlet spec of course, but also in tomcat and in struts. I would appreciate finding out the whole story on this - last time I just let it go through lack of time. If I'm in the wrong place - perhaps the JCP Servlet working group would be better - can someone point me in the right direction? Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
