Update to jdk-21.0.5+9 (EA)

- Update release notes to 21.0.5+9

- Resolves: RHEL-58797

.gitignore

@@ -23,3 +23,4 @@
 /openjdk-21.0.4+7.tar.xz
 /openjdk-21.0.5+1-ea.tar.xz
 /openjdk-21.0.5+5-ea.tar.xz
+/openjdk-21.0.5+9-ea.tar.xz

NEWS

@@ -222,6 +222,7 @@ Live versions of these release notes can be found at:
   - JDK-8329510: Update ProblemList for JFileChooser/8194044/FileSystemRootTest.java
   - JDK-8329559: Test javax/swing/JFrame/bug4419914.java failed because The End and Start buttons are not placed correctly and Tab focus does not move as expected
   - JDK-8329665: fatal error: memory leak: allocating without ResourceMark
+  - JDK-8329667: [macos] Issue with JTree related fix for JDK-8317771
   - JDK-8329995: Restricted access to `/proc` can cause JFR initialization to crash
   - JDK-8330027: Identity hashes of archived objects must be based on a reproducible random seed
   - JDK-8330063: Upgrade jQuery to 3.7.1
@@ -352,11 +353,123 @@ Live versions of these release notes can be found at:
   - JDK-8336928: GHA: Bundle artifacts removal broken
   - JDK-8337038: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java shoud set as /native
   - JDK-8337283: configure.log is truncated when build dir is on different filesystem
+  - JDK-8337622: IllegalArgumentException in java.lang.reflect.Field.get
+  - JDK-8337664: Distrust TLS server certificates issued after Oct 2024 and anchored by Entrust Root CAs
+  - JDK-8338139: {ClassLoading,Memory}MXBean::isVerbose methods are inconsistent with their setVerbose methods
   - JDK-8338286: GHA: Demote x86_32 to hotspot build only
+  - JDK-8338696: (fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux)
+  - JDK-8339869: [21u] Test CreationTime.java fails with UnsatisfiedLinkError after 8334339
+  - JDK-8341057: Add 2 SSL.com TLS roots
+  - JDK-8341059: Change Entrust TLS distrust date to November 12, 2024
 
 Notes on individual issues:
 ===========================
 
+security-libs/javax.net.ssl:
+
+JDK-8337664: Distrust TLS server certificates issued after Oct 2024 and anchored by Entrust Root CAs
+JDK-8341059: Change Entrust TLS distrust date to November 12, 2024
+====================================================================================================
+In accordance with similar plans recently announced by Google and
+Mozilla, the JDK will not trust Transport Layer Security (TLS)
+certificates issued after the 11th of November 2024 which are anchored
+by Entrust root certificates.  This includes certificates branded as
+AffirmTrust, which are managed by Entrust.
+
+Certificates issued on or before November 11th, 2024 will continue to
+be trusted until they expire.
+
+If a server's certificate chain is anchored by an affected
+certificate, attempts to negotiate a TLS session will fail with an
+Exception that indicates the trust anchor is not trusted. For example,
+
+"TLS server certificate issued after 2024-11-11 and anchored by a
+distrusted legacy Entrust root CA: CN=Entrust.net Certification
+Authority (2048), OU=(c) 1999 Entrust.net Limited,
+OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),
+O=Entrust.net"
+
+To check whether a certificate in a JDK keystore is affected by this
+change, you can the `keytool` utility:
+
+keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
+
+If any of the certificates in the chain are affected by this change,
+then you will need to update the certificate or contact the
+organisation responsible for managing the certificate.
+
+These restrictions apply to the following Entrust root certificates
+included in the JDK:
+
+Alias name: entrustevca [jdk]
+CN=Entrust Root Certification Authority
+OU=(c) 2006 Entrust, Inc.
+OU=www.entrust.net/CPS is incorporated by reference
+O=Entrust, Inc.
+C=US
+SHA256: 73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C
+
+Alias name: entrustrootcaec1 [jdk]
+CN=Entrust Root Certification Authority - EC1
+OU=(c) 2012 Entrust, Inc. - for authorized use only
+OU=See www.entrust.net/legal-terms
+O=Entrust, Inc.
+C=US
+SHA256: 02:ED:0E:B2:8C:14:DA:45:16:5C:56:67:91:70:0D:64:51:D7:FB:56:F0:B2:AB:1D:3B:8E:B0:70:E5:6E:DF:F5
+
+Alias name: entrustrootcag2 [jdk]
+CN=Entrust Root Certification Authority - G2
+OU=(c) 2009 Entrust, Inc. - for authorized use only
+OU=See www.entrust.net/legal-terms
+O=Entrust, Inc.
+C=US
+SHA256: 43:DF:57:74:B0:3E:7F:EF:5F:E4:0D:93:1A:7B:ED:F1:BB:2E:6B:42:73:8C:4E:6D:38:41:10:3D:3A:A7:F3:39
+
+Alias name: entrustrootcag4 [jdk]
+CN=Entrust Root Certification Authority - G4
+OU=(c) 2015 Entrust, Inc. - for authorized use only
+OU=See www.entrust.net/legal-terms
+O=Entrust, Inc.
+C=US
+SHA256: DB:35:17:D1:F6:73:2A:2D:5A:B9:7C:53:3E:C7:07:79:EE:32:70:A6:2F:B4:AC:42:38:37:24:60:E6:F0:1E:88
+
+Alias name: entrust2048ca [jdk]
+CN=Entrust.net Certification Authority (2048)
+OU=(c) 1999 Entrust.net Limited
+OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)
+O=Entrust.net
+SHA256: 6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77
+
+Alias name: affirmtrustcommercialca [jdk]
+CN=AffirmTrust Commercial
+O=AffirmTrust
+C=US
+SHA256: 03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7
+
+Alias name: affirmtrustnetworkingca [jdk]
+CN=AffirmTrust Networking
+O=AffirmTrust
+C=US
+SHA256: 0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0B4:1B
+
+Alias name: affirmtrustpremiumca [jdk]
+CN=AffirmTrust Premium
+O=AffirmTrust
+C=US
+SHA256: 70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A
+
+Alias name: affirmtrustpremiumeccca [jdk]
+CN=AffirmTrust Premium ECC
+O=AffirmTrust
+C=US
+SHA256: BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23
+
+Users can, *at their own risk*, remove this restriction by modifying
+the `java.security` configuration file (or override it by using the
+`java.security.properties` system property) so "ENTRUST_TLS" is no
+longer listed in the `jdk.security.caDistrustPolicies` security
+property.
+
 security-libs/javax.crypto:
 
 JDK-8322971: `KEM.getInstance()` Should Check If a Third-Party Security Provider Is Signed
@@ -402,6 +515,34 @@ timestamp.
 You can use `-Djava.security.debug=help` to display a complete list of
 supported components and options.
 
+JDK-8341057: Add 2 SSL.com TLS roots
+====================================
+The following root certificates have been added to the cacerts
+truststore:
+
+Name: SSL.com
+Alias Name: ssltlsrootecc2022
+Distinguished Name: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+
+Name: SSL.com
+Alias Name: ssltlsrootrsa2022
+Distinguished Name: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
+
+core-svc/java.lang.management:
+
+JDK-8338139: {ClassLoading,Memory}MXBean::isVerbose methods are inconsistent with their setVerbose methods
+==========================================================================================================
+In previous OpenJDK releases, the behaviour of the `isVerbose` and
+`setVerbose` methods in `ClassLoadingMXBean` and `MemoryMXBean` was
+inconsistent.  The `setVerbose` method would only alter the level of
+logging to `stdout`, setting it to `info` when passed the argument
+`true`, and `off` when passed `false`. However, the `isVerbose` method
+would check if logging was enabled on any output, causing it to return
+`true` due to the presence of file logging, even when
+`setVerbose(false)` had been called to turn off `stdout` logging.
+With this release, the `isVerbose` methods only return `true` if
+`stdout` logging is enabled.
+
 New in release OpenJDK 21.0.4 (2024-07-16):
 ===========================================
 Live versions of these release notes can be found at:

java-21-openjdk.spec

@@ -358,7 +358,7 @@
 %global origin_nice     OpenJDK
 %global top_level_dir_name   %{vcstag}
 %global top_level_dir_name_backup %{top_level_dir_name}-backup
-%global buildver        5
+%global buildver        9
 %global rpmrelease      2
 # Settings used by the portable build
 %global portablerelease 1
@@ -2532,16 +2532,16 @@ cjc.mainProgram(args)
 %endif
 
 %changelog
-* Fri Oct 11 2024 Andrew Hughes <gnu.andrew@redhat.com> - 1:21.0.5.0.5-0.2.ea
+* Fri Oct 11 2024 Andrew Hughes <gnu.andrew@redhat.com> - 1:21.0.5.0.9-0.2.ea
-- Update to jdk-21.0.5+5 (EA)
+- Update to jdk-21.0.5+9 (EA)
-- Update release notes to 21.0.5+5
+- Update release notes to 21.0.5+9
 - Switch to EA mode
 - Bump giflib version to 5.2.2 following JDK-8328999
 - Bump libpng version to 1.6.43 following JDK-8329004
 - Sync with RHEL 7 portable build:
   - Use ExclusiveArch over ExcludeArch
 - Make build scripts executable
-- Related: RHEL-58797
+- Resolves: RHEL-58797
 - Resolves: RHEL-17191
 
 * Mon Oct 07 2024 Andrew Hughes <gnu.andrew@redhat.com> - 1:21.0.4.0.7-2

sources

@@ -1,2 +1,2 @@
 SHA512 (tapsets-icedtea-6.0.0pre00-c848b93a8598.tar.xz) = 97d026212363b3c83f6a04100ad7f6fdde833d16579717f8756e2b8c2eb70e144a41a330cb9ccde9c3badd37a2d54fdf4650a950ec21d8b686d545ecb2a64d30
-SHA512 (openjdk-21.0.5+5-ea.tar.xz) = 15ab28c836b7f57b316a0204bab88d85e79b7e0a6c01a16543fb6567aea87e00921169225deb60cfe5dc62fcb98e3e1c68502ee43b4b1f8f12b27dc8da610bcf
+SHA512 (openjdk-21.0.5+9-ea.tar.xz) = 7a4a38fceec86c418ae51c3ebbe37251da75ce857300f8915107d82e649a75e9e28354f6ac20e325284ce940f0d702e3f72d14363ad99030d968236c283d425e