[Bug 65714] HTTPS connection error using NIO2 with security manager enabled
https://bz.apache.org/bugzilla/show_bug.cgi?id=65714 --- Comment #28 from Allan --- (In reply to Mark Thomas from comment #27) > (In reply to Allan from comment #25) > > Hi Mark, I have carried out a number of connectivity tests. Result as > > follow. > > > > Tomcat 8.5.72-4795df9 and 9.0.57-115334b with Oracle Java JDK 9,11,13 > > (specifically 9.0.4, 11.0.2, 13.0.2) on RHEL 7 and Windows > > HTTP - pass > > HTTPS NIO - pass > > HTTPS NIO2 - pass. > > > > Tomcat 8.5.72-4795df9 and 9.0.57-115334b with Oracle Java JRE 8 > > (1.8.0.212b31 or jdk_1.8.0.251) on RHEL 7 and Windows > > HTTP - failed > > HTTPS NIO - failed > > HTTPS NIO2 - failed > > See errors from logs below. > > Michael is right. I built the tests builds on my development machine which > uses Java 11 by default and I didn't change it. Release builds are always > made with Java 8 for Tomcat 9 and Java 7 for Tomcat 8. > > It is good that your testing confirms that the issue is fixed for Java 11. I > am confident that it will also be fixed for Java 8. That said, if you want > test builds that will run on Java 8 just let me know. Thanks for the confirmation. I thought that maybe the case. There is no need to provide a Java 8 test image as you have already explained that this will be covered in the coming release. Lets hope all goes well. Other then that, I just want to thank you and your team for the quick turn around to resolve this issue. You guys are awesome. -- 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
[Bug 65736] Improve org.apache.naming.factory.BeanFactory to mitigate JNDI injection
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736 --- Comment #3 from Christopher Schultz --- Honestly, any "feature" that significantly reduces security should be difficult to enable. My initial reaction after reading that piece was "why is forceString enabled by default?" I don't know the history of that feature, so I'm not sure how popular it is or what the use-cases are. My guess is that, mostly, there are simple uses of JNDI in Tomcat. For more "exotic" use-cases, it shouldn't be too much trouble for an admin to enable this feature explicitly. It's also not clear to me how much *more* secure things are /without/ "forceString" available. JNDI lookups are, by definition, fairly sensitive things: if you allow users to control the lookups, they can kind of ... well, look-up ANYTHING. -- 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
[Bug 65736] Improve org.apache.naming.factory.BeanFactory to mitigate JNDI injection
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736 --- Comment #4 from Remy Maucherat --- The feature was added by Rainer in Jan 2015. The idea of the bean factory is to avoid having to use custom object factories (personally: I think using custom object factories is usually better), and this forceString increased flexibility further. Normally, once you get to the point where you can configure the JNDI environment of Tomcat, you can also configure everything else, so limiting forceString shouldn't add any extra safety. -- 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
[Bug 65736] Improve org.apache.naming.factory.BeanFactory to mitigate JNDI injection
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736 --- Comment #5 from quaff --- I agree that "forceString" should be disabled by default and removed in future version, It will increase safety, "you can configure the JNDI environment of Tomcat" is more harder since it need another gadget, let's remove "org.apache.naming.factory.BeanFactory" from existing gadgets. -- 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
[Bug 65736] Improve org.apache.naming.factory.BeanFactory to mitigate JNDI injection
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736 --- Comment #6 from Rainer Jung --- The history of forceString (thanks Remy) can be seen in the log message of svn r1655312 or github d1cf73ab16da6fccde3c323e16b582be8d579008. I paste it here. I am totally open to drop it, if it now turns out to pose security risks. Enhance our naming BeanFactory. If a bean property exists which the Introspector presents us with a type that we don't have a string conversion for, but the bean actually has a method to set the property from a string, allow to provide this information to the BeanFactory. New attribute "forceString" taking a comma separated list of items as values. Each item is either a bean property name (e.g. "foo") meaning that there is a setter function "setFoo(String)" for that property. Or the item is of the form "foo=method" meaning that property "foo" can be set by calling "method(String)". This should make writing a custom bean factory obsolete in quite a few cases. Concrete use case was tibco TibjmsConnectionFactory which has an attribute SSLIdentity detected by Introspector as byte[] but which can be set by setSSLIdentity(String). Existing BeanFactory throws NamingException. Regards, Rainer -- 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
