From szegedia at gmail.com Thu Dec 26 07:04:18 2024 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 26 Dec 2024 08:04:18 +0100 Subject: Removing support for SecurityManager in Nashorn Message-ID: Hi all, Due to its lineage as integral part of OpenJDK ? and thus an attractive vector of attack ? Nashorn has a lot of code dealing with proper operation under a security manager. Most of that code is not particularly relevant now that it is not part of OpenJDK, and even less since the Security Manager was deprecated in Java 17 with JEP 411[0] and slated to be permanently disabled in Java 24 with JEP 486[1], with the removal of the API sometime in the future. The time has come to also remove Security Manager support from Nashorn. As JEP 486 states, deprecating the Security Manager had hardly any impact, proving that almost nobody uses it: "Since the release of JDK 17, the maintainers of some of the handful of frameworks and tools that supported the Security Manager have removed support for it; these include Derby, Ant, SpotBugs, and Tomcat. The maintainers of Jakarta EE removed the requirement for EE applications to support the Security Manager. We are not aware of any new projects that support the Security Manager." I guess if even Tomcat can live without the Security Manager, then so can Nashorn. Attila. -- [0] https://openjdk.org/jeps/411 [1] https://openjdk.org/jeps/486 -------------- next part -------------- An HTML attachment was scrubbed... URL: From szegedia at gmail.com Thu Dec 26 17:29:50 2024 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 26 Dec 2024 18:29:50 +0100 Subject: Nashorn 15.6 is out, Nashorn 15.5 post-mortem & Github automated testing Message-ID: Hi y'all, I released Nashorn 15.6 this morning ? the links on the website are updated to point to it. It now fixes the NPE that was triggered by Log4j being used through the JUL adapter. It's a problem with some unfortunately complicated almost-circular startup initialization between various Nashorn components that just happened to blow up in logging specifically with Log4J. Piotr P. Karwasz and I collaborated on a solution for it and I released it as Nashorn 15.5 ten days ago. Unfortunately the release was a debacle as it contained a bug that prevented Nashorn from starting up at all. The almost-circularity bit us again, only this time worse ? it was not even conditional on Log4j anymore *facepalm*. I want to stress that it being released in this state was entirely my fault ? I was devoting an odd half hour of my time to this every now and then, and apparently managed to think I'm releasing something I already reasonably tested, but then? turns out I didn't. I should've known better than to release anything without one last re-run of all tests. As soon as I noticed the problem I reverted links to 15.5 from our homepage to 15.4 and marked it in the changelog as broken. After this, I reworked the solution. It partially weakens the solution Piotr contributed, but it is still an improvement enough to retain the important effect (logging not killing client code with NPE when Log4J is used.) This is now released as Nashorn 15.6. More to the point, I added a Github workflow that runs the "ant test" target on all PRs and all pushes to the main branch; this should have been done ages ago by rights. Right now it tests on Java 11, but I also made sure tests pass with Java 21 too (they were failing because the runtime was printing Security Manager related warnings to stderr) and will soon add it to the matrix as well. All of this is to say, I'm learning the lesson from 15.5 and building out ? better late than never ? automation safeguards against this kind of scenario. Thank you to everyone who patiently waited for this to get fixed. Attila. -------------- next part -------------- An HTML attachment was scrubbed... URL: From piotr at mailing.copernik.eu Mon Dec 30 07:47:52 2024 From: piotr at mailing.copernik.eu (Piotr P. Karwasz) Date: Mon, 30 Dec 2024 08:47:52 +0100 Subject: Nashorn 15.6 is out, Nashorn 15.5 post-mortem & Github automated testing In-Reply-To: References: Message-ID: Hi Attila, On 26.12.2024 18:29, Attila Szegedi wrote: > I want to stress that it being released in this state was entirely my > fault ? I was devoting an odd half hour of my time to this every now > and then, and apparently managed to think I'm releasing something I > already reasonably tested, but then? turns out I didn't. I should've > known better than to release anything without one last re-run of all > tests. I guess the blame is to be shared. As it turns out, my patch fixed the bug reproducer, but broke all the other scripting tests we have in Log4j. Honestly I didn't run them before the 15.5 release. Would it be possible to publish Nashorn RCs to a staging Nexus repository and announce its URL on the mailing list? If there is enough delay between the RC and the release, we could run our tests and report any problems before the release reaches Maven Central. Apache releases, e.g., have a 72 hours voting period between the RC and the release. This period theoretically allows users to vote -1 if the release breaks their application. The vote is non-binding, but usually taken into consideration by the maintainers. In practice, obviously, this almost never happens, since it is a manual process, but I could run the tests before each Nashorn release. [In the future I hope that networks, such as the Transparency Exchange API[1], will allow to automatize the process] Piotr [1] https://github.com/CycloneDX/transparency-exchange-api