Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
January 17, 2017
The full version string for this update release is 1.7.0_131-b12 (where "b" means "build"). The version number is 7u131.
JDK 7u131 contains IANA time zone data version 2016i. 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 7u131 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 7u131) will expire with the release of the next critical patch update scheduled for April 18, 2017.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u131) on May 18, 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.
Improved protection for JNDI remote class loading
Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:
JDK-8158997 (not public)
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."
jarsigner -verbose -verify should print the algorithms used to sign the jar
The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.
Specifically, when "
jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property
jdk.jar.disabledAlgorithms, it will be labeled with "(weak)".
- Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key
Added security property to configure XML Signature secure validation mode
A new security property named
jdk.xml.dsig.secureValidationPolicy has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the
java.security configuration file is:
jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops
Please refer to the definition of the property in the
java.security file for more information.
Support SHA224withDSA and SHA256withDSA in the SunJSSE provider
The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions.
Serialization Filter Configuration release note
Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in JEP 290 Serialization Filtering and in <JRE>
/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled.
RMI Better constraint checking
RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness. RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service. Additional filter patterns can be configured using either a system property or a security property. The "sun.rmi.registry.registryFilter" and "sun.rmi.transport.dgcFilter" property pattern syntax is described in JEP 290 and in <JRE>
JDK-8156802 (not public)
New system property for the remote JMX connector
*New JMX agent property - jmxremote.host*
A new property,
com.sun.management.jmxremote.host, is introduced that specifies the bind address for the default JMX agent. If the latter is not specified, the default JMX agent will listen on all interfaces (0.0.0.0) and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of the
New --allow-script-in-comments option for javadoc
--allow-script-in-comments is specified.
JDK-8138725 (not public)
Increase the minimum key length to 1024 for XML Signatures
The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital signatures. Additionally, a new security property named
jdk.xml.dsig.SecureValidationPolicy has been added to the
java.security file and can be used to control the different restrictions enforced when the secure validation mode is enabled.
The secure validation mode is enabled either by setting the xml signature property
org.jcp.xml.dsig.secureValidation to true with the
javax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with a
If an XML Signature is generated or validated with a weak RSA or DSA key, an XMLSignatureException will be thrown with the message, "RSA keys less than 1024 bits are forbidden when secure validation is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled".
JDK-8140353 (not public)
Restrict certificates with DSA keys less than 1024 bits.
DSA keys less than 1024 bits are not strong enough and should be restricted in certification path building and validation. Accordingly, DSA keys less than 1024 bits have been deactivated by default by adding "DSA keySize < 1024" to the "jdk.certpath.disabledAlgorithms" security property. Applications can update this restriction in the security property ("jdk.certpath.disabledAlgorithms") and permit smaller key sizes if really needed (for example, "DSA keySize < 768").
JDK-8139565 (not public)
Add TLS v1.1 and v1.2 to the client list of default-enabled protocols
TLSv1.2 and TLSv1.1 are now enabled by default on the TLS client end-points. This is similar behavior to what already happens in JDK 8 releases.
More checks added to DER encoding parsing code
More checks are added to the DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed indefinite length encoding will now lead to IOException during parsing. Note that signatures generated using JDK default providers are not affected by this change.
JDK-8168714 (not public)
Additional access restrictions for URLClassLoader.newInstance
Class loaders created by the
java.net.URLClassLoader.newInstance methods can be used to load classes from a list of given URLs. If the calling code does not have access to one or more of the URLs and the URL artifacts that can be accessed do not contain the required class, then a ClassNotFoundException, or similar, will be thrown. Previously, a SecurityException would have been thrown when access to a URL was denied. If required to revert to the old behavior, this change can be disabled by setting the
jdk.net.URLClassPath.disableRestrictedPermissions system property.
JDK-8151934 (not public)
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 the JDK 7u131 Bug Fixes page.