Release notes for OpenJDK 17.0.5
Abstract
Preface
OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in three versions: OpenJDK 8u, OpenJDK 11u, and OpenJDK 17u.
Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your feedback on our documentation. To provide feedback, you can highlight the text in a document and add comments.
This section explains how to submit feedback.
Prerequisites
- You are logged in to the Red Hat Customer Portal.
- In the Red Hat Customer Portal, view the document in Multi-page HTML format.
Procedure
To provide your feedback, perform the following steps:
Click the Feedback button in the top-right corner of the document to see existing feedback.
NoteThe feedback feature is enabled only in the Multi-page HTML format.
- Highlight the section of the document where you want to provide feedback.
Click the Add Feedback pop-up that appears near the highlighted text.
A text box appears in the feedback section on the right side of the page.
Enter your feedback in the text box and click Submit.
A documentation issue is created.
- To view the issue, click the issue tracker link in the feedback view.
Chapter 1. Support policy for OpenJDK
Red Hat will support select major versions of OpenJDK in its products. For consistency, these versions remain similar to Oracle JDK versions that are designated as long-term support (LTS).
Red Hat supports a major version of OpenJDK for a minimum of six years from the time Red Hat first introduces OpenJDK.
OpenJDK 17 is supported on Microsoft Windows and Red Hat Enterprise Linux until November 2027.
RHEL 6 reached the end of life in November 2020. Due to this, OpenJDK is not supporting RHEL 6 as a supporting configuration..
Additional resources
See, OpenJDK Life Cycle and Support Policy (Red Hat Customer Portal)
Chapter 2. Differences from upstream OpenJDK 17
OpenJDK in Red Hat Enterprise Linux contains a number of structural changes from the upstream distribution of OpenJDK. The Microsoft Windows version of OpenJDK attempts to follow Red Hat Enterprise Linux updates as closely as possible.
The following list details the most notable Red Hat OpenJDK 17 changes:
- FIPS support. Red Hat OpenJDK 17 automatically detects whether RHEL is in FIPS mode and automatically configures OpenJDK 17 to operate in that mode. This change does not apply to OpenJDK builds for Microsoft Windows.
- Cryptographic policy support. Red Hat OpenJDK 17 obtains the list of enabled cryptographic algorithms and key size constraints from the RHEL system configuration. These configuration components are used by the Transport Layer Security (TLS) encryption protocol, the certificate path validation, and any signed JARs. You can set different security profiles to balance safety and compatibility. This change does not apply to OpenJDK builds for Microsoft Windows.
-
Red Hat OpenJDK on RHEL dynamically links against native libraries such as
zlibfor archive format support andlibjpeg-turbo,libpng, andgiflibfor image support. RHEL also dynamically links againstHarfbuzzandFreetypefor font rendering and management. This change does not apply to OpenJDK builds for Microsoft Windows. -
The
src.zipfile includes the source for all of the JAR libraries shipped with OpenJDK. - Red Hat OpenJDK on RHEL uses system-wide timezone data files as a source for timezone information.
- Red Hat OpenJDK on RHEL uses system-wide CA certificates.
- Red Hat OpenJDK on Microsoft Windows includes the latest available timezone data from RHEL.
- Red Hat OpenJDK on Microsoft Windows uses the latest available CA certificate from RHEL.
Additional resources
Chapter 3. OpenJDK features
The latest OpenJDK 17 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from previous OpenJDK 17 releases.
For all the other changes and security fixes, see OpenJDK 17.0.5 Released.
OpenJDK enhancements
OpenJDK 17 provides enhancements to features originally created in previous releases of OpenJDK.
Disabled cpu.shares parameter
Before the OpenJDK 17.0.5 release, 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 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.
The -XX:+UseContainerCpuShares argument is a deprecated feature and might be removed in a future OpenJDK release.
See JDK-8281181 (JDK Bug System).
SHA-1 Signed JARs
With the 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:
- Algorithms used to digest, sign, and optionally timestamp the JAR.
- Signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) responses that are used to verify if those certificates have been revoked.
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 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
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
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 OpenJDK 17.0.5, and you accept the security risks, you can complete the following actions:
-
Modify the
java.securityconfiguration file. Alternatively, you can preserve this file and instead create another file with the required configurations. -
Remove the
SHA1 usage SignedJAR & denyAfter 2019 01 011entry from thejdk.certpath.disabledAlgorithmssecurity property. -
Remove the
SHA1 denyAfter 2019-01-01entry from thejdk.jar.disabledAlgorithmssecurity property.
The value of jdk.certpath.disabledAlgorithms in the java.security file might be overridden by the system security policy on RHEL 8 and 9. The values used by the system security policy can be seen in the file /etc/crypto-policies/back-ends/java.config and disabled by either setting security.useSystemPropertiesFile to false in the java.security file or passing -Djava.security.disableSystemPropertiesFile=true to the JVM. These values are not modified by this release, so the values remain the same for previous releases of OpenJDK.
For an example of configuring the java.security file, see Overriding java.security properties for JBoss EAP for OpenShift (Red Hat Customer Portal).
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-:
-
Windows-<local_computer_name> -
Windows-<root_local_computer_name> -
Windows-<current_username> -
Windows-<root_username>
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 OpenJDK 17.0.5 release includes the following new system properties that you can use to control the keep-alive behavior of HTTPURLConnection:
-
http.keepAlive.time.server, which controls connections to servers. -
http.keepAlive.time.proxy, which controls connections to proxies.
Before the 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 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 OpenJDK’s HTTP protocol handler closes idle connections after a specified number of seconds.
Before the OpenJDK 17.0.5 release, the following use cases would lead to specific keep-alive behaviors for HTTPURLConnection:
-
If the server specifies the
Connection:keep-aliveheader and the server’s response containsKeep-alive:timeout=Nthen the OpenJDKkeep-alivecache on the client uses a timeout ofNseconds, whereNis an integer value. -
If the server specifies the
Connection:keep-aliveheader, but the server’s response does not contain an entry forKeep-alive:timeout=Nthen the OpenJDKkeep-alivecache on the client uses a timeout of60seconds for a proxy and5seconds for a server. -
If the server does not specify the
Connection:keep-aliveheader, the OpenJDKkeep-alivecache on the client uses a timeout of 5 seconds for all connections.
The 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.
If you set the keep-alive property and the server specifies a keep-alive time for the Keep-Alive response header, the HTTP protocol handler uses the time specified by the server. This situation is identical for a proxy.
See JDK-8278067 (JDK Bug System).
Chapter 4. Advisories related to this release
The following advisories have been issued to bugfixes and to CVE fixes included in this release:
Revised on 2022-11-02 11:15:41 UTC