RELEASE NOTES FOR: 8u151 ==================================================================================================== Notes generated: Mon Jun 03 05:49:42 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: security-libs/javax.crypto: JDK-8157561: New Security property to control crypto policy This release introduces a new feature whereby the JCE jurisdiction policy files used by the JDK can be controlled via a new Security property. In older releases, JCE jurisdiction files had to be downloaded and installed separately to allow unlimited cryptography to be used by the JDK. The download and install steps are no longer necessary. To enable unlimited cryptography, one can use the new `crypto.policy` Security property. If the new Security property (crypto.policy) is set in the java.security file, or has been set dynamically using the Security.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set the crypto.policy to a value of 'unlimited'. See the notes in the java.security file shipping with this release for more information. Note : On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the new crypto.policy Security property in the java.security file. Because the old JCE jurisdiction files are left in `/lib/security`, they may not meet the latest security JAR signing standards, which were refreshed in 6u131, 7u121, 8u111, and later updates. An exception similar to the following might be seen if the old files are used : ``` Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524) ``` security-libs: JDK-8057810: New defaults for DSA keys in jarsigner and keytool For DSA keys, the default signature algorithm for `keytool` and `jarsigner` has changed from SHA1withDSA to SHA256withDSA and the default key size for `keytool` has changed from 1024 bits to 2048 bits. Users wishing to revert to the previous behavior can use the `-sigalg` option of `keytool` and `jarsigner` and specify SHA1withDSA and the `-keysize` option of `keytool` and specify 1024. There are a few potential compatibility risks associated with this change: 1. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to specify a smaller key size (1024). 2. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on an earlier release of JDK 6 or 7 will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 3. If you use a `PKCS11` keystore, the SunPKCS11 provider does not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. security-libs/java.security: JDK-8171319: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8029659: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). ALL FIXED ISSUES, BY COMPONENT AND PRIORITY: core-libs/java.util.jar: (P2) JDK-8175053: Mach 5 builds failed on Windows/install repo after JDK-8173207 docs/guides: (P2) JDK-8180377: SunJCE section of Oracle Providers doc missing AES/GCM Cipher hotspot/gc: (P2) JDK-8179084: HotSpot VM fails to start when AggressiveHeap is set javafx/graphics: (P2) JDK-8178989: Missing copyright headers for some files javafx/other: (P2) JDK-8172805: Update copyright header for files modified in 2016 (P2) JDK-8172806: Update copyright header for files modified in 2017 javafx/web: (P2) JDK-8184448: Crash while loading gif images with more frames (P2) JDK-8170450: Crash while loading wordpress.com in HiDPI / Retina display (P2) JDK-8180825: Javafx WebView fails to render pdf.js (P2) JDK-8183292: Update to 604.1 version of WebKit (P2) JDK-8132675: VBox.setVgrow and HBox.setHgrow corrupt following controls when window resized (P2) JDK-8185132: window.requestAnimationFrame API is not working (P3) JDK-8138652: [macosx] New WebView Native Code uses private Apple APIs (P3) JDK-8178360: Build and integrate ICU from source (P3) JDK-8178440: Build libxml2 and libxslt from source (P3) JDK-8178319: Build sqlite3 from source (P3) JDK-8176729: com.sun.webkit.dom.NodeImpl#SelfDisposer is not called (P3) JDK-8165909: JavaScript to Java String conversion is not correct (P3) JDK-8179673: JVM Crash in WebPage.setBackgroundColor() during webpage navigation (Non Public API) (P3) JDK-8172836: WebView Debug build is broken (P4) JDK-8172495: Ignore __cmake_systeminformation from web module build directory (P4) JDK-8089283: Padding property of the select tag is incorrect in WebView javafx/window-toolkit: (P2) JDK-8172847: [macos] If you hit the escape key repeatedly to close the subwindow, the process crashes security-libs: (P3) JDK-8057810: New defaults for DSA keys in jarsigner and keytool security-libs/java.security: (P2) JDK-8154015: Apply algorithm constraints to timestamped code (P2) JDK-8177569: keytool should not warn if signature algorithm used in cacerts is weak (P2) JDK-8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms (P3) JDK-8179564: Missing @bug for tests added with JDK-8165367 (P3) JDK-8153146: sun/security/krb5/auto/MaxRetries.java failed with timeout (P4) JDK-8029659: Keytool, print key algorithm of certificate or key entry security-libs/javax.crypto: (P3) JDK-8157561: Ship the unlimited policy files in JDK Updates (P4) JDK-8158517: Minor optimizations to ISO10126PADDING security-libs/org.ietf.jgss:krb5: (P3) JDK-8087144: sun/security/krb5/auto/MaxRetries.java fails with Retry count is -1 less (P4) JDK-8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException