8u111 Update Release Notes
October 18, 2016
Java™ SE Development Kit 8, Update 111 (JDK 8u111)
The full version string for this update release is 1.8.0_111-b14 (where "b" means "build"). The version number is 8u111.
IANA Data 2016f
JDK 8u111 contains IANA time zone data version 2016f. For more information, refer to Timezone Data Versions in the JRE Software.
See JDK-8159684
See JDK-8159684
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u111 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_111-b14 |
| 7 | 1.7.0_121-b15 |
| 6 | 1.6.0_131-b14 |
JRE Expiration Date
The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u111) will expire with the release of the next critical patch update scheduled for January 19, 2017.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u111) on February 19, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
Certificate Changes
New JCE Code Signing Root CA
In order to support longer key lengths and stronger signature algorithms, a new JCE Provider Code Signing root certificate authority has been created and its certificate added to Oracle JDK. New JCE provider code signing certificates issued from this CA will be used to sign JCE providers from this point forward. By default, new requests for JCE provider code signing certificates will be issued from this CA.
In order to support longer key lengths and stronger signature algorithms, a new JCE Provider Code Signing root certificate authority has been created and its certificate added to Oracle JDK. New JCE provider code signing certificates issued from this CA will be used to sign JCE providers from this point forward. By default, new requests for JCE provider code signing certificates will be issued from this CA.
Existing certificates from the current JCE provider code signing root will continue to validate. However, this root CA may be disabled at some point in the future. We recommend that new certificates be requested and existing provider JARs be re-signed.
For details on the JCE provider signing process, please refer to the How to Implement a Provider in the Java Cryptography Architecture documentation.
JDK-8141340 (not public)
JDK-8141340 (not public)
Changes
client-libs/java.awt
Service Menu services
The lifecycle management of AWT menu components exposed problems on certain platforms. This fix improves state synchronization between menus and their containers.
JDK-8158993 (not public)
Service Menu services
The lifecycle management of AWT menu components exposed problems on certain platforms. This fix improves state synchronization between menus and their containers.
JDK-8158993 (not public)
core-libs/java.net
Disable Basic authentication for HTTPS tunneling
In some environments, certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the jdk.http.auth.tunneling.disabledSchemesnetworking property. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line.
Disable Basic authentication for HTTPS tunneling
In some environments, certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the jdk.http.auth.tunneling.disabledSchemesnetworking property. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line.
Additionally, the jdk.http.auth.tunneling.disabledSchemes andjdk.http.auth.proxying.disabledSchemes networking properties, and system properties of the same name, can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS, or proxying plain HTTP, respectively.
JDK-8160838 (not public)
JDK-8160838 (not public)
security-libs/java.security
Restrict JARs signed with weak algorithms and keys
This JDK release introduces new restrictions on how signed JAR files are verified. If the signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR file as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
1. Applets or Web Start Applications
2. Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR.
The list of disabled algorithms is controlled via a new security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.
The following algorithms and key sizes are restricted in this release:
Restrict JARs signed with weak algorithms and keys
This JDK release introduces new restrictions on how signed JAR files are verified. If the signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR file as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
1. Applets or Web Start Applications
2. Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR.
The list of disabled algorithms is controlled via a new security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.
The following algorithms and key sizes are restricted in this release:
- MD2 (in either the digest or signature algorithm)
- RSA keys less than 1024 bits
NOTE: We are planning to restrict MD5-based signatures in signed JARs in the January 2017 CPU.
To check if a weak algorithm or key was used to sign a JAR file, you can use the jarsigner binary that ships with this JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.
For example, to check a JAR file named test.jar, use the following command:
jarsigner -verify -J-Djava.security.debug=jar test.jar
If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!
The updated jarsigner command will exit with the following warning printed to standard output:
"Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"
To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size.
Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JAR files, the existing signature(s) should be removed from the JAR. This can be done with the zip utility, as follows:
zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'
Please periodically check the Oracle JRE and JDK Cryptographic Roadmap athttp://java.com/cryptoroadmap for planned restrictions to signed JAR files and other security components. In particular, please note the current plan is to restrict MD5-based signatures in signed JAR files in the January 2017 CPU.
To test if your JARs have been signed with MD5, add MD5 to the jdk.jar.disabledAlgorithms security property, ex:
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
and then run jarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.
JDK-8155973 (not public)
For example, to check a JAR file named test.jar, use the following command:
jarsigner -verify -J-Djava.security.debug=jar test.jar
If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!
The updated jarsigner command will exit with the following warning printed to standard output:
"Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"
To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size.
Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JAR files, the existing signature(s) should be removed from the JAR. This can be done with the zip utility, as follows:
zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'
Please periodically check the Oracle JRE and JDK Cryptographic Roadmap athttp://java.com/cryptoroadmap for planned restrictions to signed JAR files and other security components. In particular, please note the current plan is to restrict MD5-based signatures in signed JAR files in the January 2017 CPU.
To test if your JARs have been signed with MD5, add MD5 to the jdk.jar.disabledAlgorithms security property, ex:
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
and then run jarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.
JDK-8155973 (not public)
deploy
Warning message added to deployment authenticator dialog
A warning has been added to the plugin authentication dialog in cases where HTTP Basic authentication (credentials are sent unencrypted) is used while using a proxy or while not using SSL/TLS protocols:
"WARNING: Basic authentication scheme will effectively transmit your credentials in clear text. Do you really want to do this?"
JDK-8161647 (not public)
Warning message added to deployment authenticator dialog
A warning has been added to the plugin authentication dialog in cases where HTTP Basic authentication (credentials are sent unencrypted) is used while using a proxy or while not using SSL/TLS protocols:
"WARNING: Basic authentication scheme will effectively transmit your credentials in clear text. Do you really want to do this?"
JDK-8161647 (not public)
Known Issues
hotspot/jfr
Some events not available in JFR recordings on Windows
The following events are not available in the JFR recordings on Windows for release 8u111:
1. hotspot/jvm/os/processor/cpu_load
2. os/processor/context_switch_rate
This is due to regression JDK-8063089 that was introduced in 8u111 with the changes for JDK-8162419. The fix for JDK-8063089 could not be included in the 8u111 release. It will be available in the next 8u111 BPR build and in the next public release.
JDK-8063089 (not public)
Some events not available in JFR recordings on Windows
The following events are not available in the JFR recordings on Windows for release 8u111:
1. hotspot/jvm/os/processor/cpu_load
2. os/processor/context_switch_rate
This is due to regression JDK-8063089 that was introduced in 8u111 with the changes for JDK-8162419. The fix for JDK-8063089 could not be included in the 8u111 release. It will be available in the next 8u111 BPR build and in the next public release.
JDK-8063089 (not public)
deploy
JVM throws NullPointerExceptions on macOS Sierra 10.12
On macOS Sierra 10.12, if a user presses modifier keys (such as Command, Shift, or Alt) while an applet is running in a browser, an error box named “Internal Error” might be displayed. It will also show the “exec” icon in the macOS dock. The user can dismiss the applet, or try to rerun the applet while not pressing a modifier key. To fix this problem, users can install JRE 8u112.
See JDK-8165867.
JVM throws NullPointerExceptions on macOS Sierra 10.12
On macOS Sierra 10.12, if a user presses modifier keys (such as Command, Shift, or Alt) while an applet is running in a browser, an error box named “Internal Error” might be displayed. It will also show the “exec” icon in the macOS dock. The user can dismiss the applet, or try to rerun the applet while not pressing a modifier key. To fix this problem, users can install JRE 8u112.
See JDK-8165867.
Bug Fixes
This release contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see theJDK 8u111 Bug Fixes page.
- wong chee tat :)
No comments:
Post a Comment