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.
