stable

OpenJDK 17.0.5 for Fedora 37

FEDORA-2022-f687000ef7 created by ahughes a year ago for Fedora 37

New in release OpenJDK 17.0.5 (2022-10-18)

Security Fixes

  • JDK-8282252: Improve BigInteger/Decimal validation
  • JDK-8285662: Better permission resolution
  • JDK-8286077, CVE-2022-21618: Wider MultiByte conversions
  • JDK-8286511: Improve macro allocation
  • JDK-8286519: Better memory handling
  • JDK-8286526, CVE-2022-21619: Improve NTLM support
  • JDK-8286910, CVE-2022-21624: Improve JNDI lookups
  • JDK-8286918, CVE-2022-21628: Better HttpServer service
  • JDK-8287446: Enhance icon presentations
  • JDK-8288508: Enhance ECDSA usage
  • JDK-8289366, CVE-2022-39399: Improve HTTP/2 client usage
  • JDK-8289853: Update HarfBuzz to 4.4.1
  • JDK-8290334: Update FreeType to 2.12.1

Major Changes

JDK-8278067: Make HttpURLConnection Default Keep Alive Timeout Configurable

Two system properties have been added which control the keep alive behavior of HttpURLConnection in the case where the server does not specify a keep alive time. Two properties are defined for controlling connections to servers and proxies separately. They are:

  • http.keepAlive.time.server
  • http.keepAlive.time.proxy

respectively. More information about them can be found on the Networking Properties page.

JDK-8286918: Better HttpServer service

The HttpServer can be optionally configured with a maximum connection limit by setting the jdk.httpserver.maxConnections system property. A value of 0 or a negative integer is ignored and considered to represent no connection limit. In the case of a positive integer value, any newly accepted connections will be first checked against the current count of established connections and, if the configured limit has been reached, then the newly accepted connection will be closed immediately.

JDK-8281181: CPU Shares Ignored When Computing Active Processor Count

Previous JDK releases used an incorrect interpretation of the Linux cgroups parameter "cpu.shares". This might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources when the JVM is used inside a container.

Starting from this JDK release, by default, the JVM no longer considers "cpu.shares" when deciding the number of threads to be used by the various thread pools. The -XX:+UseContainerCpuShares command-line option can be used to revert to the previous behaviour. This option is deprecated and may be removed in a future JDK release.

JDK-8269039: Disabled SHA-1 Signed JARs

JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers.

To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to this policy:

  • Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.

This exception may be removed in a future JDK release. To determine if your signed JARs are affected by this change, run:

$ jarsigner -verify -verbose -certs`

on the signed JAR, and look for instances of "SHA1" or "SHA-1" and "disabled" and a warning that the JAR will be treated as unsigned in the output.

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

JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms.

Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or override it by using the java.security.properties system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2022-f687000ef7

This update has been submitted for testing by ahughes.

a year ago

This update's test gating status has been changed to 'ignored'.

a year ago

This update has been pushed to testing.

a year ago
User Icon nixuser commented & provided feedback a year ago
karma

I am able to run Apache NetBeans 15 under both the new OpenJDK 11.0.7 and also 17.0.5.

User Icon bojan commented & provided feedback a year ago
karma

Works.

This update can be pushed to stable now if the maintainer wishes

a year ago
User Icon jfoster commented & provided feedback a year ago
karma

no issues noticed

This update has been submitted for stable by bodhi.

a year ago
User Icon jpopelka commented & provided feedback a year ago
karma

works ok

User Icon nb provided feedback a year ago
karma

This update has been pushed to stable.

a year ago

Please login to add feedback.

Metadata
Type
security
Severity
medium
Karma
5
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
3
Stable by Time
7 days
Dates
submitted
a year ago
in testing
a year ago
in stable
a year ago

Automated Test Results