Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
July 14, 2020
The full version string for this update release is 1.8.0_261-b12 (where "b" means "build"). The version number is 8u261.
JDK 8u261 contains IANA time zone data version 2020a. 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 8u261 are specified in the following table:
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
8 | 1.8.0_261-b12 |
7 | 1.7.0_271-b10 |
Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u261) be used after the next critical patch update scheduled for October 20, 2020.
Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u261) on November 17, 2020. 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 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
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)
security-libs/javax.net.ssl
➜ TLS Support for RSASSA-PSS Signature Algorithms
Added support for RSASSA-PSS signature algorithms in JSSE implementation.
See JDK-8166595
security-libs/javax.net.ssl
➜ JEP 332 Transport Layer Security (TLS) 1.3
JDK 8u261 includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the Java Secure Socket Extension (JSSE) Reference Guide documentation and JEP 332.
For TLS 1.3, the following new standard algorithm names are defined:
SSLContext
algorithm name: TLSv1.3TLS 1.3 is disabled for default SSLContext("SSL" or "TLS") for client end-point.
The TLS 1.3 protocol can be enabled using several mechanisms already available in the JDK. For example, TLS 1.3 protocol can be enabled on SSL/TLS connections using SSLSocket/SSLEngine/SSLServerSocket APIs and system properties by one of the following:
sslSocket.setEnabledProtocols(new String[] { "TLSv1.3", "TLSv1.2"});
SSLContext ctx = SSLContext.getInstance("TLSv1.3");
sslParameters.setProtocols(new String[] {"TLSv1.3", "TLSv1.2"});
jdk.tls.client.protocols
system property can also be used to control the protocols in use for a TLS connection. One may launch their application with this property. For example, java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2"
enables TLSv1.3 and TLSv1.2 on client SSLSockets.https.protocols
system property can also be used to control the protocols on connection obtained through use of the HttpsURLConnection
class or URL.openStream()
operations. For example, -Dhttps.protocols=TLSv1.3,TLSv1.2
.A new system property, jdk.tls.server.protocols
, has been added to configure the default enabled protocol suite in the server side of the SunJSSE provider.
A new security property, jdk.tls.keyLimits
, has been added for TLS 1.3. When the specified amount of data of a specific algorithm has been processed, a post-handshake Key and IV Update is triggered to derive new keys.
Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to take into account when upgrading to TLS 1.3:
jdk.tls.acknowledgeCloseNotify
, is added. The default value of the system property is "false". If the system property is set to "true", a corresponding close_notify
alert will be sent when receiving a close_notify
alert, and the connection will be duplex closed.signature_algorithms_cert
extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application can use unsupported signature algorithms.com.sun.net.ssl.dhKeyExchangeFix
system property has been removed from the new TLS implementation. Improved JSSE debug logging format has been introduced to record the logger name, the logger level, the thread ID, the thread name, the time and the caller for each log item. Use the javax.net.debug=all
system property to get full debug logs.
See JDK-8145252
security-libs/javax.crypto
➜ JCE Jurisdiction Policy Files updated
Since January 2018 (8u161, 7u171) unlimited Java Cryptography Extension (JCE) Jurisdiction Policy files have been bundled with the JDK and enabled by default (see JDK Cryptographic Roadmap).
The certificate for the old stand alone jar has expired, and if used the following exception will be seen:
Caused By: java.lang.SecurityException: The jurisdiction policy files are not signed by the expected signer! (Policy files are specific per major JDK release.Ensure the correct version is installed.) at javax.crypto.JarVerifier.verifyPolicySigned(JarVerifier.java:336) at
javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:378) at
javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:323) at
javax.crypto.JceSecurity.access$000(JceSecurity.java:50) at
javax.crypto.JceSecurity$1.run(JceSecurity.java:85) at java.security.AccessController.doPrivileged(Native Method) at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:82)
If still required for older releases the re-signed files can be found at https://www.oracle.com/java/technologies/oracle-java-archive-downloads.html
security-libs/javax.net.ssl
➜ New System Properties to Configure the TLS Signature Schemes
Two new System Properties are added to customize the TLS signature schemes in JDK. jdk.tls.client.SignatureSchemes
is added for TLS client side, and jdk.tls.server.SignatureSchemes
is added for server side.
Each System Property contains a comma-separated list of supported signature scheme names specifying the signature schemes that could be used for the TLS connections.
The names are described in the "Signature Schemes" section of the Java Security Standard Algorithm Names Specification.
See JDK-8242141
security-libs/javax.net.ssl
➜ Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
The JDK SunJSSE implementation now supports the TLS FFDHE mechanisms defined in RFC 7919. If a server cannot process the supported_groups
TLS extension or the named groups in the extension, applications can either customize the supported group names with jdk.tls.namedGroups
, or turn off the FFDHE mechanisms by setting the System Property jsse.enableFFDHE
to false
.
See JDK-8140436
security-libs/javax.net.ssl
➜ Increase the priorities of GCM cipher suites
In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider.
In the SunJSSE provider, the following ciphersuites are now the most preferred by default:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases.
See JDK-8028518
security-libs
➜ Default SSL Session Cache Size Updated to 20480
The default SSL session cache size has been updated to 20480 in this JDK release
See JDK-8210985
infrastructure
➜ Toolchain Upgrade to Xcode 10.1
Build Environment Update for macOS Moved to Xcode 10.1 On macOS, the toolchain used to build the JDK has been upgraded from Xcode 4.5 to Xcode 10.1.
JDK-8232007 (not public)
security-libs/java.security
➜ Removal of Comodo Root CA Certificate
The following expired Comodo root CA certificate was removed from the cacerts
keystore:
Distinguished Name: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
See JDK-8225069
security-libs/java.security
➜ Removal of DocuSign Root CA Certificate
The following expired DocuSign root CA certificate was removed from the cacerts
keystore:
Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
See JDK-8225068
JDK 8u261 release includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). The following are descriptions of "Known Issues" which an application might encounter during a SSL handshake, post upgrade to Oracle JDK/JRE 8u261:
1. SSL handshake fails on client side with an exception message "Received fatal alert: handshake_failure"
javax.net.ssl|SEVERE|C8|....|TransportContext.java:319|Fatal (HANDSHAKE_FAILURE): Received fatal
alert: handshake_failure (
"throwable" : {
javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.Alert.createSSLException(Alert.java:117)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:187)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:154)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1198)
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1107)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:400)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:372)
Cause: One possible cause is old server intolerance to FFDHE arguments. As per TLS RFC 7919 on server behavior If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE cipher suites are acceptable to the server, the server MUST end the connection with a fatal TLS alert of type insufficient_security(71).
Solution: In Oracle JDK 8u261, Finite Field Diffie-Hellman Ephemeral (FFDHE) is enabled by default. User can disable FFDHE via security property "-Djsse.enableFFDHE=false on the server (See JDK-8252716)
2. Post upgrade to 8u261 client application encounters close_notify exception during a ClientHello SSL handshake.
javax.net.ssl.SSLProtocolException: Received close_notify during handshake
at sun.security.ssl.Alert.createSSLException(Unknown Source)
at sun.security.ssl.Alert.createSSLException(Unknown Source)
at sun.security.ssl.TransportContext.fatal(Unknown Source)
at sun.security.ssl.TransportContext.fatal(Unknown Source)
at sun.security.ssl.TransportContext.fatal(Unknown Source)
at sun.security.ssl.Alert$AlertConsumer.consume(Unknown Source)
at sun.security.ssl.TransportContext.dispatch(Unknown Source)
at sun.security.ssl.SSLTransport.decode(Unknown Source)
at sun.security.ssl.SSLSocketImpl.decode(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown
Cause: In case of an SSL abbreviated handshake (session resumption) SSL client is adding extra extensions than the agreed protocol's supported extensions. While it is TLS RFC complaint, some old non-compliant server implementations may reject this ClientHello.
Solution: As a work around specify System property -Djdk.tls.client.protocols=
3. On upgrade to 8u261, under certain conditions user application may observe higher CPU utilization and slower response time.
The following method reference count would increase in memory profilers:
HashMap$Node[] java.util.HashMap.resize()
void sun.security.ssl.SSLSessionContextImpl.put(SSLSessionImpl)
void sun.security.util.MemoryCache.put(Object, Object)
Object java.util.HashMap.put(Object, Object)
Object java.util.HashMap.putVal(int, Object, Object, boolean, boolean)
HashMap$Node[] java.util.HashMap.resize()
Cause: In 8u261, System Property SSLSessionContext.getSessionCacheSize default value was changed from 0 to 20480 ( see JDK-8210985 ) The change was made since with larger heaps, applications are running into situations where the cache ends up with several million entries at the 24 hour mark, at which time many of them are invalidated at almost the same time, which can result in multi-minute pauses, which are effectively service failures.
Solution: Revert back to JDK 8u251 behaviour by setting System Property "-Djavax.net.ssl.sessionCacheSize=0" (set number of entries in the SSL session cache to infinite)
4. TLS connection issues with applications using javax.net.ssl.SSLEngine
Cause: The internal implementation of the SSLEngine and associated classes has been reworked with the introduction of TLS v1.3 support. Buffer usage has been improved in the SSLEngine area.
Solution: If an SSLEngine application encounters issues after upgrading to JDK 8u261 or later, refer to the Java 8 API to ensure application code is correct. In particular, applications using SSLEngine should not just depend on SSLEngineResult.Status.BUFFER_UNDERFLOW or SSLEngineResult.Status.BUFFER_OVERFLOW results in order to flush pending data. Buffers should always be flushed after an SSLEngine wrap operation if such a call produces data (where SSLEngineResult.Status.OK may be returned).
5. Post upgrading client machine with 8u261, during a SSL handshake, the "Request Authentication" popup dialog does not display any certificates if user has set deployment System Property deployment.security.clientauth.keystore.auto=false
Cause: If deployment.security.clientauth.keystore.auto=false in the deployment.properties file Java Plugin and Java Web Start show “Request Authentication” dialog regardless the number of available certificates. However due to some modifications introduced by TLS 1.3 framework sometimes the list of available certificates might be empty.
Solution: There are two possible ways to resolve the issue:
Set deployment System Property deployment.security.clientauth.keystore.auto=true
Upgrade to new version 8u281 of Oracle JDK contained the fix for the issue
(see JDK-8253502 )
6. Post upgrade to 8u261, during a SSL handshake, user may observe the following "Warning" message in the log
javax.net.ssl|WARNING|03|Finalizer|2020-08-31 09:42:20.203 EDT|null:-1|SSLSocket duplex close failed (
"throwable" : {
java.net.SocketException: Socket is not connected
at java.net.Socket.shutdownOutput(Unknown Source)
at sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(Unknown Source)
at sun.security.ssl.SSLSocketImpl.duplexCloseOutput(Unknown Source)
at sun.security.ssl.SSLSocketImpl.close(Unknown Source)
at sun.security.ssl.BaseSSLSocketImpl.finalize(Unknown Source)
at java.lang.System$2.invokeFinalize(Unknown Source)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)}
Cause: JDK 8u261 introduced a new format for TLS logging. Additional data is now captured per event and logged. Exceptions handled by the JDK TLS library code may print verbose information about the cause of such exceptions when logging is enabled.
Solution: User can safely ignore these Warning messages
7. Ensure you 3rd party libraries are fully patched. Examples: Bouncy Castle, Apache, OpenSSL, Jetty
Symptoms: New/Unexpected issues from 3rd party library software being used in conjunction with the JDK.
Cause: The new TLS implementation introduces significant changes to the internal, underlying, design of the JDK TLS security libraries. The new design has exposed some bugs in 3rd party software libraries. For the most part, these issues have already been patched in such 3rd party libraries.
Examples include: Apache http-core Bouncy Castle Jetty
Solution: It's good practice to ensure that 3rd party library products being used in conjunction with the JDK TLS API are patched and up to date.
On Windows 7, the Internet Explorer 11 (IE 11) JavaScript engine does not interact properly with Java Applets because, beginning with 8u261, the JDK/JRE is compiled with VisualStudio 2017. For example, an application that uses the JavaScript methods setTimeout()
and setInterval()
may cause IE 11 to hang when a modal dialog is shown by a Java Applet.
javafx/media
➜ Media Playback Does Not Work on Ubuntu 20.04
Media playback does not work on Ubuntu 20.04. This affects all media formats (such as, mp4, mp3, wav, etc.). In some cases, an error will be thrown. In other cases, the media player will switch to the ready state, but playback will not start. There is no workaround for this issue. This issue should be resolved by JDK-8239095.
JDK-8245501 (not public)
core-libs/java.util:collections
➜ Better Listing of Arrays
The preferred way to copy a collection is to use a "copy constructor." For example, to copy a collection into a new ArrayList, one would write new ArrayList<>(collection)
. In certain circumstances, an additional, temporary copy of the collection's contents might be made in order to improve robustness. If the collection being copied is exceptionally large, then the application should be (aware of/monitor) the significant resources required involved in making the copy.
JDK-8231800 (not public)
Communication with the alternatives framework of JDK RPM installer starting from 8u261 has changed. JDK RPM installers of prior versions registered two groups of symbolic links with alternatives framework, java
and javac
. Some names of links in these groups were duplicated, which resulted in installation failures for some versions of alternatives framework. The JDK RPM installer beginning with 8u261 doesn't register the javac
group with alternatives framework. All links unique to the javac
group have been moved into the java
group, but the set of symbolic links registered by the installer have not changed; only the duplicated links have been dropped.
The implication of this change is that if this version of JDK and 8u251 or older versions of the JDK are installed and the previous version is uninstalled, the symbolic links from the java
group that are managed by the alternatives framework will be deleted. To restore deleted links, run the command:
/usr/sbin/alternatives --auto java
install/install
➜ Java Mission Control Is No Longer Bundled With the JDK
This version of the JDK no longer includes Java Mission Control (JMC). The jmc
launcher has been removed from the JDK bin
directory, and the missioncontrol
directory has been removed from the JDK lib
directory. The .jfr
file association is not registered by JDK installers. JMC is now available as a separate download. Please visit https://www.oracle.com/javase/jmc for more information.
JDK-8244662 (not public)
deploy/plugin
➜ Possible Hang of Internet Explorer 11 With JDK 8u261 on Windows 7
On Windows 7, the Internet Explorer 11 (IE 11) JavaScript engine does not interact properly with Java Applets because, beginning with 8u261, the JDK/JRE is compiled with VisualStudio 2017. For example, an application that uses the JavaScript methods setTimeout()
and setInterval()
may cause IE 11 to hang when a modal dialog is shown by a Java Applet.
JDK-8244937 (not public)
core-svc/java.lang.management
➜ OperatingSystemMXBean Methods Inside a Container Return Container Specific Data
When executing in a container, or other virtualized operating environment, the following OperatingSystemMXBean
methods in this release return container specific information, if available. Otherwise, they return host specific data:
getFreePhysicalMemorySize()
getTotalPhysicalMemorySize()
getFreeSwapSpaceSize()
getTotalSwapSpaceSize()
getSystemCpuLoad()
See JDK-8226575
security-libs/javax.net.ssl
➜ BoringSSL Rejects JSSE TLS 1.3 HTTPS Connections When status_request Extension Is Disabled
BoringSSL is an SSL library deployed on some popular websites such as those run by Google/YouTube. An interoperability issue with the BoringSSL library can lead to a connection failure if TLSv1.3 is presented as the only enabled protocol in the ClientHello message and the certificate status_request extension is disabled. Enabling the certificate status_request extension by setting the jdk.tls.client.enableStatusRequestExtension
system property to true
will provide mitigation in such scenarios.
See JDK-8241360
This release also 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 8u261 Bug Fixes page.