April 17, 2018
The full version string for this update release is 10.0.1+10 (where "+" means "build"). The version number is 10.0.1.
For the April CPU, two different JDK10 bundles have been released:
This page provides release notes for both bundles. Content that only applies to a specific bundle is presented in sections that contain either OpenJDK or Oracle JDK in their titles. Sections that do not contain OpenJDK or Oracle JDK in their titles apply to both bundles.
JDK 10.0.1 contains IANA time zone data version 2018c. For more information, refer to Timezone Data Versions in the JRE Software.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 10.0.1 are specified in the following table:
|JRE Family Version||JRE Security Baseline |
(Full Version String)
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 10.0.1) will expire with the release of the next critical patch update scheduled for July 17, 2018.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 10.0.1) on August 17, 2018. 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.
The specification of
javax.crypto.CipherOutputStream has been clarified to indicate that this class catches BadPaddingException and other exceptions thrown by failed integrity checks during decryption. These exceptions are not re-thrown, so the client is not informed that integrity checks have failed. Because of this behavior, this class may not be suitable for use with decryption in an authenticated mode of operation (for example, GCM) if the application requires explicit notification when authentication fails. These applications can use the Cipher API directly as an alternative to using this class.
A new security property named
jceks.key.serialFilter has been introduced. If this filter is configured, the JCEKS KeyStore uses it during the deserialization of the encrypted Key object stored inside a SecretKeyEntry. If it is not configured or if the filter result is UNDECIDED (for example, none of the patterns match), then the filter configured by
jdk.serialFilter is consulted.
If the system property
jceks.key.serialFilter is also supplied, it supersedes the security property value defined here.
The filter pattern uses the same format as
jdk.serialFilter. The default pattern allows
javax.crypto.spec.SecretKeySpec but rejects all the others.
Customers storing a SecretKey that does not serialize to the above types must modify the filter to make the key extractable.
The secure validation mode of the XML Signature implementation has been enhanced to restrict EC keys less than 224 bits by default. The secure validation mode is enabled either by setting the property
org.jcp.xml.dsig.secureValidation to true with the
javax.xml.crypto.XMLCryptoContext.setProperty() method, or by running the code with a SecurityManager.
To improve the strength of SSL/TLS connections, 3DES cipher suites have been disabled in SSL/TLS connections in the JDK via the
jdk.tls.disabledAlgorithms Security Property.
This release contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 10.0.1 Bug Fixes page.