I'd advocate disable-by-default in 10x. But we use it to tame tests, which I appreciate. That will take more time to come up with another substitute. Let's pay attention to what the Lucene project does.
On Fri, Dec 13, 2024 at 1:37 PM Eric Pugh <ep...@opensourceconnections.com> wrote: > What does this mean for us? Time to remove the Security Manager in 10x? > > > > > > > Begin forwarded message: > > > > From: David Delabassee <david.delabas...@oracle.com.INVALID> > > Subject: JDK 24 Feature Freeze | Permanently Disabling the Security > Manager > > Date: December 13, 2024 at 10:32:02 AM EST > > To: "d...@tika.apache.org" <d...@tika.apache.org> > > Reply-To: d...@tika.apache.org > > > > Welcome to the final OpenJDK Quality Outreach update of 2024! > > > > JDK 24, scheduled for General Availability on March 18, 2025 [1], is now > in Rampdown Phase One (RDP1) [2]. At this point, the overall JDK 24 feature > set is frozen and only low-risk enhancements might still be considered. You > will find below the final list of the 24 JEPs that were integrated into JDK > 24 as well as JDK 24 technical materials in the last section. > > > > This QO update also covers 3 important heads-ups related to security, > integrity and JDK 24. > > > > The next key milestone is early February with the first JDK 24 Release > Candidate builds. That means that we have a few weeks, modulo the end of > year break, to find and hopefully address any issue that your projects > might encounter. So, please let us know if you encounter any issue with the > JDK early-access builds. > > > > [1] https://openjdk.org/projects/jdk/24/ > > [2] https://mail.openjdk.org/pipermail/jdk-dev/2024-December/009672.html > > > > > > # Heads-up - JDK 24: Permanently Disabling the Security Manager > > > > Introduced to enforce the principle of the least privilege, the Security > Manager was designed to prevent unauthorized code from accessing sensitive > resources (ex. files, network connections, etc.). While effective in > theory, it has fallen short in practice for multiple reasons: complexity, > limited adoption, maintenance overhead and evolving threat landscape. > > > > In Java 17, the Security Manager was deprecated for removal under JEP > 411 [3]. In JDK 24, its functionality will be effectively disabled via JEP > 486 [4]. Key changes include: > > > > - Disabling the Security Manager - it will no longer be possible to > enable the SM at startup using command-line options, nor will it be > possible to install a custom SM during runtime. > > - Rendering the Security Manager API non-functional - the SM API will > remain present for compatibility but will no longer have any operational > effect. > > - Improving maintainability - thousands of lines of code dedicated to > supporting the Security Manager will be removed, freeing OpenJDK > contributors to implement modern security features. > > > > Developers and enterprises using older Java versions or legacy > applications relying on the Security Manager will retain access until JDK > 24. Beyond that, they are encouraged to transition to alternative > sandboxing and API interception mechanisms. > > > > ## Call to Action > > > > The deprecation of the Security Manager in JDK 17 had little to no > impact on most Java developers. Warnings issued in JDK 17–23 generated > minimal discussion in the Java ecosystem, highlighting its limited > relevance. Furthermore, major frameworks and tools (ex. Jakarta EE, Ant, > Tomcat, etc.) have already removed support for the Security Manager, > reinforcing the trend. > > > > For applications still dependent on the Security Manager, the JDK offers > options to identify and address its usage: > > > > - jdeprscan [5] scans a JAR file for the usage of deprecated API > elements, and it helps find code using these methods. > > - Messages on the console warnings highlight Security Manager usage > during runtime. > > - Check how you launch your Java application - with the Security Manager > allowed or enabled via command line options, or policy files that require > it to be installed and configured. > > > > These tools give code maintainers the necessary insights to transition > away from the Security Manager before its complete removal in future JDK > releases. By taking these steps, you will ensure a smooth transition from > the Security Manager while adopting more effective security practices. > > > > This is a summary; for more details, make sure to read JEP 486 [4]. > > > > [3] https://openjdk.org/jeps/411 > > [4] https://openjdk.org/jeps/486 > > [5] https://dev.java/learn/jvm/tools/core/jdeprscan/ > > > > > > # Heads-up - JDK 24: Prepares Restricted Native Access > > > > Any interaction between Java code and native code, be it via the Java > Native Interface (JNI) API or the Foreign Function & Memory (FFM) API, is > risky in the sense that it can compromise the integrity of applications and > of the Java Platform itself, for example by causing JVM crashes, even after > the native code completed execution. According to the policy of integrity > by default, all JDK features that are capable of breaking integrity must > obtain explicit approval from the application’s developer. JDK 24, by means > of JEP 472 [6], prepares that by aligning the behaviors of JNI and FFM by: > > > > - Printing warnings for all restricted operations (with the goal to turn > these into exceptions in a future release). > > - Expanding the command-line options `--enable-native-access` and > `--illegal-native-access` to govern restricted operations of both APIs. > > > > Note that this is a change for JNI, which used to not trigger such > warnings, as well as for FFM, which used to forbid restricted operations by > default. Starting with JDK 24, both APIs behave uniformly by printing > warnings. In the future, both APIs will throw exceptions instead. The > intent is neither to discourage the use of, deprecate, or even remove JNI > nor to restrict the behavior of native code called via JNI or FFM. The goal > is to ensure that applications and the Java Platform have integrity by > default while giving application operators the tools they need to > selectively opt-out where needed. > > > > This is a summary; for more details, please read the full Heads-Up [7] > and JEP 472 [6]. > > > > [6] https://openjdk.org/jeps/472 > > [7] https://inside.java/2024/12/09/quality-heads-up/ > > > > > > # Heads-up - JDK 24: Security Properties Files Inclusion > > > > > > Managing security properties across multiple JDK releases can be a > challenge, particularly in environments requiring centralized control and > distinct security profiles. To address this and starting with JDK 24, the > Java Platform now allows the main security properties file > (`${java.home}/conf/security/java.security`) or any file specified via the > `java.security.properties` system property to include additional files. > This inclusion is recursive, allowing for nested configurations, provided > no cycles occur. > > > > The `include` keyword is reserved and cannot be used to define security > properties, as any attempt to do so results in an unchecked > `IllegalArgumentException`. The inclusion mechanism enhances security by > explicitly listing files in the main configuration file, preventing > misconfigurations by throwing a fatal error if a file is missing or > inaccessible. It also forbids including directories or URLs, ensuring > strict control over which files are included. Users must ensure proper > permissions for included files to avoid tampering, such as enforcing secure > file permissions. The system supports a clear priority for security > property overrides based on the order of inclusion, and updates to a single > file automatically propagate across all configurations. > > > > This enhancement offers better control and adaptability over Java > security properties for developers, system administrators and > infrastructure engineers. > > > > This is a summary; for more details, please read the full Heads-Up [8] > and the JDK 24 release notes [9]. > > > > [8] https://inside.java/2024/12/10/quality-heads-up/ > > [9] https://jdk.java.net/24/release-notes#JDK-8319332 > > > > > > # JDK 24 Early-Access Builds > > > > The JDK 24 early-access builds 28 are available [10] and are provided > under the GNU General Public License v2, with the Classpath Exception. The > Release Notes are available here [11]. > > > > ## JEPs integrated into JDK 24: > > - JEP 404: Generational Shenandoah (Experimental) > > - JEP 450: Compact Object Headers (Experimental) > > - JEP 472: Prepare to Restrict the Use of JNI > > - JEP 475: Late Barrier Expansion for G1 > > - JEP 478: Key Derivation Function API (Preview) > > - JEP 479: Remove the Windows 32-bit x86 Port > > - JEP 483: Ahead-of-Time Class Loading & Linking > > - JEP 484: Class-File API > > - JEP 485: Stream Gatherers > > - JEP 486: Permanently Disable the Security Manager > > - JEP 487: Scoped Values (4th Preview) > > - JEP 488: Primitive Types in Patterns, instanceof, and switch (2nd > Preview) > > - JEP 489: Vector API (9th Incubator) > > - JEP 490: ZGC: Remove the Non-Generational Mode > > - JEP 491: Synchronize Virtual Threads without Pinning > > - JEP 492: Flexible Constructor Bodies (3rd Preview) > > - JEP 493: Linking Run-Time Images without JMODs > > - JEP 494: Module Import Declarations (2nd Preview) > > - JEP 495: Simple Source Files and Instance Main Methods (4th Preview) > > - JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation > Mechanism > > - JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature > Algorithm > > - JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe > > - JEP 499: Structured Concurrency (4th Preview) > > - JEP 501: Deprecate the 32-bit x86 Port for Removal > > > > ## Changes in recent JDK 24 builds that may be of interest: > > - JDK-8345015: Remove unused method lookup_time_t_function [Reported by > JaCoCo] > > - JDK-8344352: 32-bit builds crash after JDK-8305895 [Reported by JaCoCo] > > - JDK-8344299: SM cleanup in javax.naming modules > > - JDK-8343791: Socket.connect API should document whether the socket > will be closed… > > - JDK-8340359: Remove javax.naming.Context.APPLET > > - JDK-8337199: Add jcmd Thread.vthread_scheduler and > Thread.vthread_pollers diagnostic commands > > - JDK-8313367: SunMSCAPI cannot read Local Computer certs w/o Windows > elevation > > - JDK-8341964: Add mechanism to disable different parts of TLS cipher > suite > > - JDK-8341553: Remove UseCompactObjectHeaders extra CDS archives > > - JDK-8343001: Adjust XSLT and XPath Extension Function Property > > - JDK-8341551: Revisit jdk.internal.loader.URLClassPath.JarLoader after > JEP 486 > > - JDK-8333582: Update CLDR to Version 46.0 > > - JDK-8341975: Unable to set encoding for IO.println, IO.print and > IO.readln > > - JDK-8342075: HttpClient: improve HTTP/2 flow control checks > > - JDK-8326949: Authorization header is removed when a proxy > Authenticator is set on HttpClient > > - JDK-8341566: Add Reader.of(CharSequence) > > - JDK-8338536: Permanently disable remote code downloading in JNDI > > - JDK-8343004: Adjust JAXP limits > > - JDK-8343020: (fs) Add support for SecureDirectoryStream on macOS > > - JDK-8344882: (bf) Temporary direct buffers should not count against > the upper limit on direct buffer memory > > - JDK-8335912: Add an operation mode to the jar command when extracting > to not overwriting existing files > > - JDK-8245545: Disable TLS_RSA cipher suites > > - JDK-8319993: Update Unicode Data Files to 16.0.0 > > - JDK-8343881: java.lang.classfile.Attribute attributeName() method > should return Utf8Entry > > - JDK-8338021: Support new unsigned and saturating vector operators in > VectorAPI > > - JDK-8343150: Change URLClassLoader.getPermissions to return empty > PermissionCollection > > > > Note: A complete list of changes can be found here [12]. > > > > [10] https://jdk.java.net/24/ > > [11] https://jdk.java.net/24/release-notes > > [12] https://github.com/openjdk/jdk/compare/jdk-24+21...jdk-24+28 > > > > > > # Topics of Interest > > > > - Java 24 Performance Improvements & Deprecations > > https://www.youtube.com/watch?v=oTc16DAMTqg > > > > - Java 24 Language & API Changes > > https://inside.java/2024/12/05/newscast-81/ > > > > - Java 24 Stops Pinning Virtual Threads (Almost) > > https://inside.java/2024/11/21/newscast-80/ > > > > - Detoxifying the JDK Source Code > > > https://stuartmarks.wordpress.com/2024/12/12/detoxifying-the-jdk-source-code/ > > > > - Better Java Streams with Gatherers - JEP Cafe > > https://inside.java/2024/11/26/jepcafe23/ > > > > - Java Language Futures - Fall 2024 Edition > > https://inside.java/2024/10/30/devoxxbelgium-java-language-futures/ > > > > - Ask the Java Architects > > https://inside.java/2024/11/14/devoxxbelgium-ask-architects/ > > > > - Pattern Matching in Java - Past, Present, Future > > https://inside.java/2024/11/11/devoxxbelgium-pattern-matching/ > > > > - Monitoring Java Application Security with JDK tools and JFR Events > > https://inside.java/2024/11/17/devoxxbelgium-security/ > > > > - ZGC Automatic Heap Sizing #JVMLS > > https://inside.java/2024/11/09/jvmls-zgc/ > > > > - Postcards from the Peak of Complexity > > https://inside.java/2024/11/03/devoxxbelgium-complexity-peak/ > > > > - Release Your (Java) Projects Like OpenJDK > > https://inside.java/2024/10/31/newscast-79/ > > > > - Are Virtual Threads Going to Make Reactive Programming Irrelevant? > > https://inside.java/2024/10/28/javazone-virtual-threads/ > > > > - A Sneak Peek at StableValue and SegmentMapper > > https://inside.java/2024/10/24/devoxxbelgium-stablevalues/ > > > > - Advancing AI by Accelerating Java on Parallel Architectures > > https://inside.java/2024/10/23/java-and-ai/ > > > > > > ~ > > > > As always, ping me if you find any issues while testing your project(s) > with the latest JDK early-access builds. And as the year-end is fast > approaching, let me wish you all the best for the upcoming holidays. See > you in 2025 with Java 24, JavaOne and Java 25! > > > > PS: Please let me know if you don't want to receive these OpenJDK > Quality Outreach updates anymore. > > > > --David > > _______________________ > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. > >
