7u281 Update Release Notes
Java™ SE Development Kit 7, Update 281 (JDK 7u281)
October 20, 2020
The full version string for this update release is 1.7.0_281-b06 (where "b" means "build"). The version number is 7u281.
IANA Data 2020a
JDK 7u281 contains IANA time zone data version 2020a. For more information, refer to Timezone Data Versions in the JRE Software.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u281 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 7 | 1.7.0_281-b06 |
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 Bulletins. This JRE (version 7u281) will expire with the release of the next critical patch update scheduled for January 19, 2021.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u281) on February 19, 2021. 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.
New Features
hotspot/runtime
➜ JDK/JRE Runtime Windows Visual Studio Library (DLL) Dependency Changes
As part of ongoing maintenance, the Microsoft Visual Studio 2017 tool chain will be used to build JDK 7 and JDK 8 for Windows. JDK 8u261, in the July 2020 CPU, was built with Visual Studio 2017. With the release of the January 2021 CPU, JDK 7u291 will move to Visual Studio 2017.
Moving to Visual Studio 2017 for JDK 7 and JDK 8 requires changing the runtime library that the JDK/JRE depends on. Before this change, JDK/JRE implementations used and shipped the Microsoft Visual C++ 2010 SP1 Redistributable Package (x86/x64) that included MSVCR100.dll [a][b]. Microsoft Visual Studio 2017 uses a different set of libraries/DLLs.
Native applications (including JNI) that have depended on and assumed the presence of MSCVR100.dll in the JDK/JRE directory will fail to run. When this happens, users will see an error such as:
"The code execution cannot proceed because MSVCR100.dll was not found. Reinstalling the program may fix this problem."
These applications should be rebuilt and shipped with modern C++ runtime dependencies that use a later instance of Visual Studio. Applications should not depend on DLLs included with the JDK/JRE that are not documented in the product as offering support for the specification or other functionality in Java SE.
[a] http://support.microsoft.com/kb/2019667
[b] https://docs.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2020
JDK-8246783 (not public)
Weak named curves are disabled by default by adding them to the following disabledAlgorithms security properties: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms, and jdk.jar.disabledAlgorithms. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each disabledAlgorithms property would be overwhelming. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all of the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, precede the full property name with the keyword include. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.
To restore the named curves, remove the include jdk.disabled.namedCurves either from specific or from all disabledAlgorithms security properties.
To restore one or more curves, remove the specific named curve(s) from the jdk.disabled.namedCurves property.
Curves that are disabled through jdk.disabled.namedCurves include the following:
secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
A new system property, jdk.tls.maxHandshakeMessageSize, has been added to set the maximum allowed size for the handshake message in TLS/DTLS handshaking. The default value of the system property is 32768 (32 kilobytes).
A new system property, jdk.tls.maxCertificateChainLength, has been added to set the maximum allowed length of the certificate chain in TLS/DTLS handshaking. The default value of the system property is 10.
The keytool and jarsigner tools have been updated to warn users when weak cryptographic algorithms are used in keys, certificates, and signed JARs before they are disabled. The weak algorithms are set in the jdk.security.legacyAlgorithms security property in the java.security configuration file. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys.
Other notes
A new environment property,
jdk.jndi.ldap.mechsAllowedToSendCredentials, has been added to
control which LDAP authentication mechanisms are allowed to send
credentials over clear LDAP connections - a connection not secured
with TLS. An encrypted LDAP connection is a connection opened
by using ldaps scheme, or a connection opened by using ldap scheme
and then upgraded to TLS with a STARTTLS extended operation.
The value of the property, which is by default not set, is a comma
separated list of the mechanism names that are permitted to authenticate
over a clear connection. If a value is not specified for the property, then all mechanisms
are allowed. If the specified value is an empty list, then no mechanisms are
allowed (except for none and anonymous). The default value for this property is 'null'
( i.e. System.getProperty("jdk.jndi.ldap.mechsAllowedToSendCredentials") returns 'null'). To explicitly permit all mechanisms to authenticate over a clear connection, the property
value can be set to "all". If a connection is downgraded from
encrypted to clear, then only the mechanisms that are explicitly permitted are allowed.
The property can be supplied to the LDAP context environment map, or set globally as a system property. When both are supplied, the environment map takes precedence.
Note: none and anonymous authentication mechanisms are exempted
from these rules and are always allowed regardless of the property value.
The following root certificates have been added to the cacerts truststore:
+ SSL Corporation
+ sslrootrsaca
DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US
+ sslrootevrsaca
DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US
+ sslrooteccca
DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US
The following root certificate has been added to the cacerts truststore:
+ Entrust
+ entrustrootcag4
DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only",
OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
The deserialization of java.lang.reflect.Proxy objects can be limited by setting the system property jdk.serialProxyInterfaceLimit.
The limit is the maximum number of interfaces allowed per Proxy in the stream.
Setting the limit to zero prevents any Proxies from being deserialized including Annotations, a limit of less than 2 might interfere with RMI operations.
From 7u281 and on, the JRE is installed by the enterprise JRE installer rather than the consumer JRE. This has resulted in two changes:
(1) No public JRE installation GUI is offered during the JDK install. This removes the user’s ability during the JDK installation to specify a custom directory in the GUI for the public JRE. If a directory other than the default is desired, use the /INSTALLDIRPUBJRE command-line option to set an installation path for the JRE. Users can also deselect the public JRE during the JDK installation and install it separately.
(2) The JRE is installed into a version directory instead of a family directory. Because the consumer JRE is no longer installed, there is no patch-in-place. It uses the enterprise JRE method of installing, which includes the full version.
Bug Fixes
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 7u281 Bug Fixes page.