OpenJDK 8u352-b04 EA Released

[Andrew Hughes]

I've made available an early access source bundle for 8u352, based on
the tag jdk8u352-b04:

https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b04-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b04-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

1edfc4123f097acbf312552635e0c768152e545139312ebd7b102837cd4ed694  openjdk8u352-b04-ea.tar.xz
e5c856d33f22a25ad3666c60ac57ecd031b7219c8892656abf1fb4e160a3131f  openjdk8u352-b04-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b04-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u352-b04:
  - JDK-8214427: probable bug in logic of ConcurrentHashMap.addCount()
  - JDK-8245263: Enable TLSv1.3 by default on JDK 8u for Client roles
  - JDK-8288763: Pack200 extraction failure with invalid size

Notes on individual issues:
===========================

security-libs/javax.net.ssl:

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"});
slsSocket.setSSLParameters(params);

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220901/74076276/signature.asc>