8u101 Update Release Notes
July 19, 2016
Java™ SE Development Kit 8, Update 101 (JDK 8u101)
The full version string for this update release is 1.8.0_101-b13 (where "b" means "build"). The version number is 8u101.
IANA Data 2016d
JDK 8u101 contains IANA time zone data version 2016d. For more information, refer to Timezone Data Versions in the JRE Software.
See JDK-8151876
See JDK-8151876
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u101 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_101-b13 |
| 7 | 1.7.0_111-b13 |
| 6 | 1.6.0_121-b09 |
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 8u101) will expire with the release of the next critical patch update scheduled for October 19, 2016.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u101) on November 19, 2016. 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 DTrust certificates added to root CAs
Two new root certificates have been added:
Two new root certificates have been added:
D-TRUST Root Class 3 CA 2 2009
alias: dtrustclass3ca2
DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
alias: dtrustclass3ca2
DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
D-TRUST Root Class 3 CA 2 EV 2009
alias: dtrustclass3ca2ev
DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
See JDK-8153080
alias: dtrustclass3ca2ev
DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
See JDK-8153080
New IdenTrust certificates added to root CAs
Three new root certificates have been added:
Three new root certificates have been added:
IdenTrust Public Sector Root CA 1
alias: identrustpublicca
DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
alias: identrustpublicca
DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
IdenTrust Commercial Root CA 1
alias: identrustcommercial
DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
alias: identrustcommercial
DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
IdenTrust DST Root CA X3
alias: identrustdstx3
DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8154757
alias: identrustdstx3
DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8154757
Comodo Root CA removed
The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file.
See JDK-8141540
The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file.
See JDK-8141540
Sonera Class1 CA removed
The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file.
See JDK-8141276
The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file.
See JDK-8141276
Changes
other-libs/corba
Improve access control to javax.rmi.CORBA.ValueHandler
The javax.rmi.CORBA.Util class provides methods that can be used by stubs and ties to perform common operations. It also acts as a factory for ValueHandlers. Thejavax.rmi.CORBA.ValueHandler interface provides services to support the reading and writing of value types to GIOP streams. The security awareness of these utilities has been enhanced with the introduction of a permissionjava.io.SerializablePermission("enableCustomValueHanlder"). This is used to establish a trust relationship between the users of the javax.rmi.CORBA.Util andjavax.rmi.CORBA.ValueHandler APIs.
The required permission is "enableCustomValueHanlder" SerializablePermission. Third party code running with a SecurityManager installed, but not having the new permission while invokingUtil.createValueHandler(), will fail with an AccessControlException.
This permission check behaviour can be overridden, in JDK8u and previous releases, by defining a system property, "jdk.rmi.CORBA.allowCustomValueHandler".
As such, external applications that explicitly call javax.rmi.CORBA.Util.createValueHandlerrequire a configuration change to function when a SecurityManager is installed and neither of the following two requirements is met:
1. The java.io.SerializablePermission("enableCustomValueHanlder") is not granted by SecurityManager.
2. In the case of applications running on JDK8u and before, the system property"jdk.rmi.CORBA.allowCustomValueHandler" is either not defined or is defined equal to "false" (case insensitive).
Improve access control to javax.rmi.CORBA.ValueHandler
The javax.rmi.CORBA.Util class provides methods that can be used by stubs and ties to perform common operations. It also acts as a factory for ValueHandlers. Thejavax.rmi.CORBA.ValueHandler interface provides services to support the reading and writing of value types to GIOP streams. The security awareness of these utilities has been enhanced with the introduction of a permissionjava.io.SerializablePermission("enableCustomValueHanlder"). This is used to establish a trust relationship between the users of the javax.rmi.CORBA.Util andjavax.rmi.CORBA.ValueHandler APIs.
The required permission is "enableCustomValueHanlder" SerializablePermission. Third party code running with a SecurityManager installed, but not having the new permission while invokingUtil.createValueHandler(), will fail with an AccessControlException.
This permission check behaviour can be overridden, in JDK8u and previous releases, by defining a system property, "jdk.rmi.CORBA.allowCustomValueHandler".
As such, external applications that explicitly call javax.rmi.CORBA.Util.createValueHandlerrequire a configuration change to function when a SecurityManager is installed and neither of the following two requirements is met:
1. The java.io.SerializablePermission("enableCustomValueHanlder") is not granted by SecurityManager.
2. In the case of applications running on JDK8u and before, the system property"jdk.rmi.CORBA.allowCustomValueHandler" is either not defined or is defined equal to "false" (case insensitive).
Please note that the "enableCustomValueHanlder" typo will be corrected in the October 2016 releases. In those and future JDK releases, "enableCustomValueHandler" will be the correct SerializationPermission to use.
JDK-8079718 (not public)
JDK-8079718 (not public)
security-libs/java.security
Support added to jarsigner for specifying timestamp hash algorithm
A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream.
See JDK-8038837
Support added to jarsigner for specifying timestamp hash algorithm
A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream.
See JDK-8038837
security-libs/javax.crypto
MSCAPI KeyStore can handle same-named certificates
Java SE KeyStore does not allow certificates that have the same aliases (http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html).
However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names. The fix for JDK-6483657 makes it possible to operate on such non-uniquely named certificates through the Java API by artificially making the visible aliases unique.
Please note, this fix does not enable creating same-named certificates with the Java API. It only allows you to deal with same-named certificates that were added to the keystore by 3rd party tools.
It is still recommended that your design not use multiple certificates with the same name. In particular, the following sentence will not be removed from the Java documentation:
"In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case."
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html)
See JDK-6483657
MSCAPI KeyStore can handle same-named certificates
Java SE KeyStore does not allow certificates that have the same aliases (http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html).
However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names. The fix for JDK-6483657 makes it possible to operate on such non-uniquely named certificates through the Java API by artificially making the visible aliases unique.
Please note, this fix does not enable creating same-named certificates with the Java API. It only allows you to deal with same-named certificates that were added to the keystore by 3rd party tools.
It is still recommended that your design not use multiple certificates with the same name. In particular, the following sentence will not be removed from the Java documentation:
"In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case."
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html)
See JDK-6483657
deploy
Deployment Tookit API methods no longer install JRE
The Deployment Toolkit API installLatestJRE() and installJRE(requestedVersion)methods from deployJava.js and the install() method from dtjava.js no longer install the JRE. If a user's version of Java is below the security baseline, it redirects the user to java.com to get an updated JRE.
JDK-8148310 (not public)
Deployment Tookit API methods no longer install JRE
The Deployment Toolkit API installLatestJRE() and installJRE(requestedVersion)methods from deployJava.js and the install() method from dtjava.js no longer install the JRE. If a user's version of Java is below the security baseline, it redirects the user to java.com to get an updated JRE.
JDK-8148310 (not public)
security-libs/java.security
DomainCombiner will no longer consult runtime policy for static ProtectionDomain objects when combining ProtectionDomain objects
Applications which use static ProtectionDomain objects (created using the 2-arg constructor) with an insufficient set of permissions may now get an AccessControlException with this fix. They should either replace the static ProtectionDomain objects with dynamic ones (using the 4-arg constructor) whose permission set will be expanded by the current Policy or construct the static ProtectionDomain object with all the necessary permissions.
JDK-8147771 (not public)
DomainCombiner will no longer consult runtime policy for static ProtectionDomain objects when combining ProtectionDomain objects
Applications which use static ProtectionDomain objects (created using the 2-arg constructor) with an insufficient set of permissions may now get an AccessControlException with this fix. They should either replace the static ProtectionDomain objects with dynamic ones (using the 4-arg constructor) whose permission set will be expanded by the current Policy or construct the static ProtectionDomain object with all the necessary permissions.
JDK-8147771 (not public)
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 8u101 Bug Fixes page.
Known Issues
deploy
JRE 8u101 is not recognized by Internet Explorer (IE) when using static class ID
When a static class id is used to launch an applet or web start application while using JRE 8u101, users will get an unwanted dialogue box stating that they either use the latest JRE or cancel the launch even though they have installed and are using the latest JRE (JRE 8u101).
JRE 8u101 is not recognized by Internet Explorer (IE) when using static class ID
When a static class id is used to launch an applet or web start application while using JRE 8u101, users will get an unwanted dialogue box stating that they either use the latest JRE or cancel the launch even though they have installed and are using the latest JRE (JRE 8u101).
This specific case is only applicable on Windows and IE.
We do not recommend using static class id for JRE version selection (since JDK 5u6, Dec 2005) per http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.
To work around this issue, users can do one of the following two things:
(1) Hit launch with the latest version (8u101) and ignore the warning.
(2) Install JRE 8u102 instead of JRE 8u101 to avoid this issue.
(1) Hit launch with the latest version (8u101) and ignore the warning.
(2) Install JRE 8u102 instead of JRE 8u101 to avoid this issue.
To address this issue, developers can do one of the following two things:
(1) Use a dynamic class id instead of static class id.
(2) Use java_version when using an HTML applet or a JNLP descriptor when using JNLP.
(1) Use a dynamic class id instead of static class id.
(2) Use java_version when using an HTML applet or a JNLP descriptor when using JNLP.
JDK-8147457 (not public)
- wong chee tat :)
No comments:
Post a Comment