--------------------------------------------------------------------------------Fedora Update Notification
FEDORA-2022-dedbb92a08
2022-11-10 22:04:44.634216
--------------------------------------------------------------------------------Name        : java-1.8.0-openjdk
Product     : Fedora 37
Version     : 1.8.0.352.b08
Release     : 2.fc37
URL         : https://openjdk.org/
Summary     : OpenJDK 8 Runtime Environment
Description :
The OpenJDK 8 runtime environment.

--------------------------------------------------------------------------------Update Information:

# New in release OpenJDK 8u352 (2022-10-18)  * [Release
announcement](https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015706.html) * [Full release
notes](https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u352.html)  ## 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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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 `enqueue`method 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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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); ~~~
--------------------------------------------------------------------------------ChangeLog:

* Wed Oct 19 2022 Andrew Hughes  - 1:1.8.0.352.b08-1
- Update to shenandoah-jdk8u352-b08 (GA)
- Update release notes for shenandoah-8u352-b08.
- Switch to GA mode for final release.
* Sun Oct 16 2022 Andrew Hughes  - 1:1.8.0.352.b07-0.2.ea
- Update in-tree tzdata to 2022e with JDK-8294357 & JDK-8295173
- Add test to ensure timezones can be translated
* Wed Oct 12 2022 Andrew Hughes  - 1:1.8.0.352.b07-0.1.ea
- Update to shenandoah-jdk8u352-b07 (EA)
- Update release notes for shenandoah-8u352-b07.
- Switch to EA mode for 8u352 pre-release builds.
- Rebase FIPS patch against 8u352-b07
--------------------------------------------------------------------------------This update can be installed with the "dnf" update program. Use
su -c 'dnf upgrade --advisory FEDORA-2022-dedbb92a08' at the command
line. For more information, refer to the dnf documentation available at
https://dnf.readthedocs.io/en/latest/command_ref.html

All packages are signed with the Fedora Project GPG key. More details on the
GPG keys used by the Fedora Project can be found at
https://fedoraproject.org/security/
--------------------------------------------------------------------------------_______________________________________________
package-announce mailing list -- package-announce@lists.fedoraproject.org
To unsubscribe send an email to package-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/
Do not reply to spam, report it: https://pagure.io/login/

Fedora 37: java-1.8.0-openjdk 2022-dedbb92a08

November 10, 2022
# New in release OpenJDK 8u352 (2022-10-18) * [Release announcement](https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015706.html) * [Full release notes](https://builds.sh...

Summary

The OpenJDK 8 runtime environment.

# New in release OpenJDK 8u352 (2022-10-18) * [Release

announcement](https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015706.html) * [Full release

notes](https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u352.html) ## 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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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 `enqueue`method 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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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); ~~~

* Wed Oct 19 2022 Andrew Hughes - 1:1.8.0.352.b08-1

- Update to shenandoah-jdk8u352-b08 (GA)

- Update release notes for shenandoah-8u352-b08.

- Switch to GA mode for final release.

* Sun Oct 16 2022 Andrew Hughes - 1:1.8.0.352.b07-0.2.ea

- Update in-tree tzdata to 2022e with JDK-8294357 & JDK-8295173

- Add test to ensure timezones can be translated

* Wed Oct 12 2022 Andrew Hughes - 1:1.8.0.352.b07-0.1.ea

- Update to shenandoah-jdk8u352-b07 (EA)

- Update release notes for shenandoah-8u352-b07.

- Switch to EA mode for 8u352 pre-release builds.

- Rebase FIPS patch against 8u352-b07

su -c 'dnf upgrade --advisory FEDORA-2022-dedbb92a08' at the command

line. For more information, refer to the dnf documentation available at

https://dnf.readthedocs.io/en/latest/command_ref.html

All packages are signed with the Fedora Project GPG key. More details on the

GPG keys used by the Fedora Project can be found at

https://fedoraproject.org/security/

package-announce mailing list -- package-announce@lists.fedoraproject.org

To unsubscribe send an email to package-announce-leave@lists.fedoraproject.org

Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/

Do not reply to spam, report it: https://pagure.io/login/

FEDORA-2022-dedbb92a08 2022-11-10 22:04:44.634216 Product : Fedora 37 Version : 1.8.0.352.b08 Release : 2.fc37 URL : https://openjdk.org/ Summary : OpenJDK 8 Runtime Environment Description : The OpenJDK 8 runtime environment. # New in release OpenJDK 8u352 (2022-10-18) * [Release announcement](https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015706.html) * [Full release notes](https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u352.html) ## 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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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 `enqueue`method 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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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); ~~~ * Wed Oct 19 2022 Andrew Hughes - 1:1.8.0.352.b08-1 - Update to shenandoah-jdk8u352-b08 (GA) - Update release notes for shenandoah-8u352-b08. - Switch to GA mode for final release. * Sun Oct 16 2022 Andrew Hughes - 1:1.8.0.352.b07-0.2.ea - Update in-tree tzdata to 2022e with JDK-8294357 & JDK-8295173 - Add test to ensure timezones can be translated * Wed Oct 12 2022 Andrew Hughes - 1:1.8.0.352.b07-0.1.ea - Update to shenandoah-jdk8u352-b07 (EA) - Update release notes for shenandoah-8u352-b07. - Switch to EA mode for 8u352 pre-release builds. - Rebase FIPS patch against 8u352-b07 su -c 'dnf upgrade --advisory FEDORA-2022-dedbb92a08' at the command line. For more information, refer to the dnf documentation available at https://dnf.readthedocs.io/en/latest/command_ref.html All packages are signed with the Fedora Project GPG key. More details on the GPG keys used by the Fedora Project can be found at https://fedoraproject.org/security/ package-announce mailing list -- package-announce@lists.fedoraproject.org To unsubscribe send an email to package-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/ Do not reply to spam, report it: https://pagure.io/login/

Change Log

References

Update Instructions

Severity
Product : Fedora 37
Version : 1.8.0.352.b08
Release : 2.fc37
URL : https://openjdk.org/
Summary : OpenJDK 8 Runtime Environment

Related News