Release notes for Red Hat build of OpenJDK 17.0.5

Red Hat will support select major versions of Red Hat build of OpenJDK in its products. For consistency, these versions remain similar to Oracle JDK versions that are designated as long-term support (LTS).

A major version of Red Hat build of OpenJDK will be supported for a minimum of six years from the time that version is first introduced. For more information, see the OpenJDK Life Cycle and Support Policy.

Red Hat build of OpenJDK in Red Hat Enterprise Linux contains a number of structural changes from the upstream distribution of OpenJDK. The Microsoft Windows version of Red Hat build of OpenJDK attempts to follow Red Hat Enterprise Linux updates as closely as possible.

The following list details the most notable Red Hat build of OpenJDK 17 changes:

The latest Red Hat build of OpenJDK 17 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from previous Red Hat build of OpenJDK 17 releases.

Red Hat build of OpenJDK enhancements

Red Hat build of OpenJDK 17 provides enhancements to features originally created in previous releases of Red Hat build of OpenJDK.

Disabled cpu.shares parameter

Before the Red Hat build of OpenJDK 17.0.5 release, Red Hat build of OpenJDK used an incorrect interpretation of the cpu.shares parameter, which belongs to Linux control groups, also known as cgroups. The parameter might cause a Java Virtual machine (JVM) to use fewer CPUs than available, which can impact the JVM’s CPU resources and performance when it operates inside a container.

The Red Hat build of OpenJDK 17.0.5 release configures a JVM to no longer use the cpu.shares parameter when determining the number of threads for a thread pool. If you want to revert this configuration, pass the -XX:+UseContainerCpuShares argument on JVM startup.

See JDK-8281181 (JDK Bug System).

SHA-1 Signed JARs

With the Red Hat build of OpenJDK 17.0.5 release, JARs signed with SHA-1 algorithms are restricted by default and treated as if they were unsigned. These restrictions apply to the following algorithms:

Additionally, the restrictions apply to signed Java Cryptography Extension (JCE) providers.

To reduce the compatibility risk for JARs that have been previously timestamped, the restriction does not apply to any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019. This exception might be removed in a future Red Hat build of OpenJDK release.

To determine if your JAR file is impacted by the restriction, you can issue the following command in your CLI:

jarsigner -verify -verbose -certs

$ jarsigner -verify -verbose -certs

From the output of the previous command, search for instance of SHA1 , SHA-1, or disabled. Additionally, search for any warning messages that indicate that the JAR will be treated as unsigned. For example:

Signed by "CN="Signer""
Digest algorithm: SHA-1 (disabled)
Signature algorithm: SHA1withRSA (disabled), 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

Signed by "CN="Signer""
Digest algorithm: SHA-1 (disabled)
Signature algorithm: SHA1withRSA (disabled), 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

Consider replacing or re-signing any JARs affected by the new restrictions with stronger algorithms.

If your JAR file is impacted by this restriction, you can remove the algorithm and re-sign the file with a stronger algorithm, such as SHA-256. If you want to remove the restriction on SHA-1 signed JARs for Red Hat build of OpenJDK 17.0.5, and you accept the security risks, you can complete the following actions:

See JDK-8269039 (JDK Bug System).

SunMSCAPI provider supports new Microsoft Windows keystore types

The SunMSCAPI provider supports the following Microsoft Windows keystore types where you must append your local namespace to Windows-:

By specifying any of these types, you can provide access to your local computer’s location for the Microsoft Windows keystore. Thereby providing the keystore access to certificates that are stored on your local system.

See JDK-6782021 (JDK Bug System).

System properties for controlling the keep-alive behavior of HTTPURLConnection

The Red Hat build of OpenJDK 17.0.5 release includes the following new system properties that you can use to control the keep-alive behavior of HTTPURLConnection:

Before the Red Hat build of OpenJDK 17.0.5 release, a server or a proxy with an unspecified keep-alive time might cause an idle connection to remain open for a period defined by a hard-coded default value.

With Red Hat build of OpenJDK 17.0.5, you can use system properties to change the default value for the keep-alive time. The keep-alive properties control this behavior by changing the HTTP keep-alive time of either a server or proxy, so that Red Hat build of OpenJDK’s HTTP protocol handler closes idle connections after a specified number of seconds.

Before the Red Hat build of OpenJDK 17.0.5 release, the following use cases would lead to specific keep-alive behaviors for HTTPURLConnection:

The Red Hat build of OpenJDK 17.0.5 release maintains the previously described behavior, but you can now specify the timeouts in the second and third listed use cases by using the http.keepAlive.time.server and http.keepAlive.time.proxy properties, rather than having to rely on the default settings.

See JDK-8278067 (JDK Bug System).

The following advisories have been issued to bugfixes and to CVE fixes included in this release:

Revised on 2024-05-03 15:36:36 UTC