RELEASE NOTES FOR: 8u191 ==================================================================================================== Notes generated: Mon Apr 01 18:52:22 CEST 2024 Hint: Prefix bug IDs with https://bugs.openjdk.org/browse/ to reach the relevant JIRA entry. JAVA ENHANCEMENT PROPOSALS (JEP): None. RELEASE NOTES: hotspot/runtime: JDK-8146115: Java Improvements for Docker Containers The following changes have been introduced in JDK 10 to improve the execution and configurability of Java running in Docker containers: * JDK-8146115 Improve docker container detection and resource configuration usage The JVM has been modified to be aware that it is running in a Docker container and will extract container specific configuration information instead of querying the operating system. The information being extracted is the number of CPUs and total memory that have been allocated to the container. The total number of CPUs available to the Java process is calculated from any specified cpu sets, cpu shares or cpu quotas. This support is only available on Linux based platforms. This new support is enabled by default and can be disabled in the command line with the JVM option: `-XX:-UseContainerSupport` In addition, this change adds a JVM option that provides the ability to specify the number of CPUs that the JVM will use: `-XX:ActiveProcessorCount=count` This count overrides any other automatic CPU detection logic in the JVM. * JDK-8186248 Allow more flexibility in selecting Heap % of available RAM Three new JVM options have been added to allow Docker container users to gain more fine grained control over the amount of system memory that will be used for the Java Heap: * `-XX:InitialRAMPercentage` * `-XX:MaxRAMPercentage` * `-XX:MinRAMPercentage` These options replace the deprecated Fraction forms (`-XX:InitialRAMFraction`, `-XX:MaxRAMFraction`, and `-XX:MinRAMFraction`). * JDK-8179498 attach in linux should be relative to /proc/pid/root and namespace aware This bug fix corrects the attach mechanism when trying to attach from a host process to a Java process that is running in a Docker container. security-libs/java.security: JDK-8189949: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8191031: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8180289: jarsigner treats timestamped signed jar invalid after the signer cert expires If a jar file was signed with a timestamp when the signer certificate was still valid, it should be valid even after the signer certificate expires. However, jarsigner will incorrectly show a warning that that signer's certificate chain is not validated. This will be fixed in a future release. JDK-8191844: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP ALL FIXED ISSUES, BY COMPONENT AND PRIORITY: client-libs/java.awt: (P2) JDK-8208353: Upgrade libpng to 1.6.35 docs/guides: (P3) JDK-8175871: Deployment.properties file example is incorrect (P3) JDK-8173224: Document jdk.tls.legacyAlgorithms security property (P4) JDK-8198835: Typo in URL for XML section in developer guides hotspot/runtime: (P3) JDK-8146115: Improve docker container detection and resource configuration usage infrastructure/build: (P3) JDK-8033251: Use DWARF debug symbols for Linux 32-bit as default install/install: (P3) JDK-8206875: [L10N]Truncation issue happens on the final dialog for pt on Mac other-libs/other: (P4) JDK-8142927: Feed some text to STDIN in ProcessTools.executeProcess() security-libs/java.security: (P2) JDK-8198240: Allow cacerts test to pass when GTECyberTrust root expires (P2) JDK-8209452: VerifyCACerts.java failed with "At least one cacert test failed" (P3) JDK-8203793: cacerts/VerifyCACerts.java fails with java.lang.Exception: At least one cacert test failed (P3) JDK-8130132: jarsigner should emit warning if weak algorithms or keysizes are used (P3) JDK-8180289: jarsigner treats timestamped signed jar invalid after the signer cert expires (P3) JDK-8189949: Remove Baltimore Cybertrust Code Signing CA (P3) JDK-8191844: Remove SECOM root (secomevrootca1) (P3) JDK-8191031: Remove several Symantec Root CAs (P3) JDK-8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh failing (cert expired?) (P4) JDK-8049834: Two security tools tests do not run with only JRE security-libs/javax.net.ssl: (P2) JDK-8074462: Handshake messages can be strictly ordered (P4) JDK-8193892: Impact of noncloneable MessageDigest implementation security-libs/jdk.security: (P3) JDK-8172529: Use PKIXValidator in jarsigner