FEDORA-2022-f687000ef7

Packages in this update:

java-17-openjdk-17.0.5.0.8-1.fc37

Update description:

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

Release announcement
Full release notes

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.

Read More

FEDORA-2022-f76014ae17

Packages in this update:

java-17-openjdk-17.0.5.0.8-2.fc36

Update description:

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

Release announcement
Full release notes

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.

Read More

FEDORA-2022-5d494ab9ab

Packages in this update:

java-17-openjdk-17.0.5.0.8-2.fc35

Update description:

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

Release announcement
Full release notes

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.

Read More

FEDORA-2022-dedbb92a08

Packages in this update:

java-1.8.0-openjdk-1.8.0.352.b08-2.fc37

Update description:

New in release OpenJDK 8u352 (2022-10-18)

Release announcement
Full release notes

Security Fixes

JDK-8282252: Improve BigInteger/Decimal validation
JDK-8285662: Better permission resolution
JDK-8286511: Improve macro allocation
JDK-8286519: Better memory handling
JDK-8286526, CVE-2022-21619: Improve NTLM support
JDK-8286533, CVE-2022-21626: Key X509 usages
JDK-8286910, CVE-2022-21624: Improve JNDI lookups
JDK-8286918, CVE-2022-21628: Better HttpServer service
JDK-8288508: Enhance ECDSA usage

Major Changes

JDK-8201793: (ref) Reference object should not support cloning

java.lang.ref.Reference::clone method always throws CloneNotSupportedException. Reference objects cannot be
meaningfully cloned. To create a new Reference object, call the constructor to create a Reference object with the same referent and reference queue instead.

JDK-8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing

java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and get() method will return null in OpenJDK 8u352.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid memory leak because its referent is no longer referenced. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, NullPointerException may be thrown. Such
code will need to be updated.

JDK-8071507: (ref) Clear phantom reference as soft and weak references do

This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.

An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC’ed earlier – previously the referent is kept alive until PhantomReference objects are GC’ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.

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-8282859: Enable TLSv1.3 by Default on JDK 8 for Client Roles

The TLSv1.3 implementation is now enabled by default for client roles
in 8u352. It has been enabled by default for server roles since 8u272.

Note that TLS 1.3 is not directly compatible with previous
versions. Enabling it on the client may introduce compatibility issues
on either the server or the client side. Here are some more details on
potential compatibility issues that you should be aware of:

TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions
use a duplex-close policy. For applications that depend on the
duplex-close policy, there may be compatibility issues when
upgrading to TLS 1.3.

The signature_algorithms_cert extension requires that pre-defined
signature algorithms are used for certificate authentication. In
practice, however, an application may use non-supported signature
algorithms.

The DSA signature algorithm is not supported in TLS 1.3. If a server
is configured to only use DSA certificates, it cannot upgrade to TLS
1.3.

The supported cipher suites for TLS 1.3 are not the same as TLS 1.2
and prior versions. If an application hard-codes cipher suites which
are no longer supported, it may not be able to use TLS 1.3 without
modifying the application code.

The TLS 1.3 session resumption and key update behaviors are
different from TLS 1.2 and prior versions. The compatibility should
be minimal, but it could be a risk if an application depends on the
handshake details of the TLS protocols.

The TLS 1.3 protocol can be disabled by using the jdk.tls.client.protocols
system property:

java -Djdk.tls.client.protocols=”TLSv1.2″ …

Alternatively, an application can explicitly set the enabled protocols
with the javax.net.ssl APIs e.g.

sslSocket.setEnabledProtocols(new String[] {“TLSv1.2”});

or:

SSLParameters params = sslSocket.getSSLParameters();
params.setProtocols(new String[] {“TLSv1.2”});
sslSocket.setSSLParameters(params);

Read More

FEDORA-2022-361f34f2a9

Packages in this update:

java-1.8.0-openjdk-1.8.0.352.b08-2.fc36

Update description:

New in release OpenJDK 8u352 (2022-10-18)

Release announcement
Full release notes

Security Fixes

JDK-8282252: Improve BigInteger/Decimal validation
JDK-8285662: Better permission resolution
JDK-8286511: Improve macro allocation
JDK-8286519: Better memory handling
JDK-8286526, CVE-2022-21619: Improve NTLM support
JDK-8286533, CVE-2022-21626: Key X509 usages
JDK-8286910, CVE-2022-21624: Improve JNDI lookups
JDK-8286918, CVE-2022-21628: Better HttpServer service
JDK-8288508: Enhance ECDSA usage

Major Changes

JDK-8201793: (ref) Reference object should not support cloning

java.lang.ref.Reference::clone method always throws CloneNotSupportedException. Reference objects cannot be
meaningfully cloned. To create a new Reference object, call the constructor to create a Reference object with the same referent and reference queue instead.

JDK-8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing

java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and get() method will return null in OpenJDK 8u352.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid memory leak because its referent is no longer referenced. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, NullPointerException may be thrown. Such
code will need to be updated.

JDK-8071507: (ref) Clear phantom reference as soft and weak references do

This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.

An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC’ed earlier – previously the referent is kept alive until PhantomReference objects are GC’ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.

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-8282859: Enable TLSv1.3 by Default on JDK 8 for Client Roles

The TLSv1.3 implementation is now enabled by default for client roles
in 8u352. It has been enabled by default for server roles since 8u272.

Note that TLS 1.3 is not directly compatible with previous
versions. Enabling it on the client may introduce compatibility issues
on either the server or the client side. Here are some more details on
potential compatibility issues that you should be aware of:

TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions
use a duplex-close policy. For applications that depend on the
duplex-close policy, there may be compatibility issues when
upgrading to TLS 1.3.

The signature_algorithms_cert extension requires that pre-defined
signature algorithms are used for certificate authentication. In
practice, however, an application may use non-supported signature
algorithms.

The DSA signature algorithm is not supported in TLS 1.3. If a server
is configured to only use DSA certificates, it cannot upgrade to TLS
1.3.

The supported cipher suites for TLS 1.3 are not the same as TLS 1.2
and prior versions. If an application hard-codes cipher suites which
are no longer supported, it may not be able to use TLS 1.3 without
modifying the application code.

The TLS 1.3 session resumption and key update behaviors are
different from TLS 1.2 and prior versions. The compatibility should
be minimal, but it could be a risk if an application depends on the
handshake details of the TLS protocols.

The TLS 1.3 protocol can be disabled by using the jdk.tls.client.protocols
system property:

java -Djdk.tls.client.protocols=”TLSv1.2″ …

Alternatively, an application can explicitly set the enabled protocols
with the javax.net.ssl APIs e.g.

sslSocket.setEnabledProtocols(new String[] {“TLSv1.2”});

or:

SSLParameters params = sslSocket.getSSLParameters();
params.setProtocols(new String[] {“TLSv1.2”});
sslSocket.setSSLParameters(params);

Read More

FEDORA-2022-b050ae8974

Packages in this update:

java-1.8.0-openjdk-1.8.0.352.b08-2.fc35

Update description:

New in release OpenJDK 8u352 (2022-10-18)

Release announcement
Full release notes

Security Fixes

JDK-8282252: Improve BigInteger/Decimal validation
JDK-8285662: Better permission resolution
JDK-8286511: Improve macro allocation
JDK-8286519: Better memory handling
JDK-8286526, CVE-2022-21619: Improve NTLM support
JDK-8286533, CVE-2022-21626: Key X509 usages
JDK-8286910, CVE-2022-21624: Improve JNDI lookups
JDK-8286918, CVE-2022-21628: Better HttpServer service
JDK-8288508: Enhance ECDSA usage

Major Changes

JDK-8201793: (ref) Reference object should not support cloning

java.lang.ref.Reference::clone method always throws CloneNotSupportedException. Reference objects cannot be
meaningfully cloned. To create a new Reference object, call the constructor to create a Reference object with the same referent and reference queue instead.

JDK-8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing

java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and get() method will return null in OpenJDK 8u352.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid memory leak because its referent is no longer referenced. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, NullPointerException may be thrown. Such
code will need to be updated.

JDK-8071507: (ref) Clear phantom reference as soft and weak references do

This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.

An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC’ed earlier – previously the referent is kept alive until PhantomReference objects are GC’ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.

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-8282859: Enable TLSv1.3 by Default on JDK 8 for Client Roles

The TLSv1.3 implementation is now enabled by default for client roles
in 8u352. It has been enabled by default for server roles since 8u272.

Note that TLS 1.3 is not directly compatible with previous
versions. Enabling it on the client may introduce compatibility issues
on either the server or the client side. Here are some more details on
potential compatibility issues that you should be aware of:

TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions
use a duplex-close policy. For applications that depend on the
duplex-close policy, there may be compatibility issues when
upgrading to TLS 1.3.

The signature_algorithms_cert extension requires that pre-defined
signature algorithms are used for certificate authentication. In
practice, however, an application may use non-supported signature
algorithms.

The DSA signature algorithm is not supported in TLS 1.3. If a server
is configured to only use DSA certificates, it cannot upgrade to TLS
1.3.

The supported cipher suites for TLS 1.3 are not the same as TLS 1.2
and prior versions. If an application hard-codes cipher suites which
are no longer supported, it may not be able to use TLS 1.3 without
modifying the application code.

The TLS 1.3 session resumption and key update behaviors are
different from TLS 1.2 and prior versions. The compatibility should
be minimal, but it could be a risk if an application depends on the
handshake details of the TLS protocols.

The TLS 1.3 protocol can be disabled by using the jdk.tls.client.protocols
system property:

java -Djdk.tls.client.protocols=”TLSv1.2″ …

Alternatively, an application can explicitly set the enabled protocols
with the javax.net.ssl APIs e.g.

sslSocket.setEnabledProtocols(new String[] {“TLSv1.2”});

or:

SSLParameters params = sslSocket.getSSLParameters();
params.setProtocols(new String[] {“TLSv1.2”});
sslSocket.setSSLParameters(params);

Read More

Multiple security issues were discovered in Chromium, which could result
in the execution of arbitrary code, denial of service or information
disclosure.

Read More