Red Hat build of OpenJDK 21.0.7 のリリースノート
概要
はじめに リンクのコピーリンクがクリップボードにコピーされました!
Open Java Development Kit (OpenJDK) は、Java Platform Standard Edition (Java SE) のオープンソース実装です。Red Hat build of OpenJDK は、8u、11u、17u、21u の 4 つのバージョンで利用できます。
Red Hat build of OpenJDK 向けパッケージは、Red Hat Enterprise Linux および Microsoft Windows で利用でき、Red Hat Ecosystem Catalog の JDK および JRE として同梱されています。
Red Hat build of OpenJDK ドキュメントへのフィードバック リンクのコピーリンクがクリップボードにコピーされました!
エラーを報告したり、ドキュメントの改善を提案したりするには、Red Hat Jira アカウントにログインし、課題を送信してください。Red Hat Jira アカウントをお持ちでない場合は、アカウントを作成するように求められます。
手順
- 次のリンクをクリックして チケットを作成します。
- Summary に課題の簡単な説明を入力します。
- Description に課題や機能拡張の詳細な説明を入力します。問題があるドキュメントのセクションへの URL も記載してください。
- Create をクリックすると、課題が作成され、適切なドキュメントチームに転送されます。
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Red Hat build of OpenJDK のサポートポリシー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、Red Hat build of OpenJDK の一部のメジャーバージョンを製品でサポートします。一貫性を保つために、これらのバージョンは長期サポート (LTS) として指定されている Oracle JDK バージョンと同様のままとなります。
Red Hat build of OpenJDK のメジャーバージョンは、最初に導入された時点から少なくとも 6 年間サポートされます。詳細は、OpenJDK のライフサイクルおよびサポートポリシー を参照してください。
RHEL 6 のライフサイクルは 2020 年 11 月に終了しました。このため、Red Hat build of OpenJDK は、サポート対象の設定として RHEL 6 をサポートしていません。
第2章 アップストリームの OpenJDK 21 との相違点 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux の Red Hat build of OpenJDK には、OpenJDK のアップストリームディストリビューションとは異なる構造上の変更が数多く含まれています。Microsoft Windows バージョンの Red Hat build of OpenJDK は、Red Hat Enterprise Linux の更新にできる限り従います。
以下は、Red Hat build of OpenJDK 21 における最も注目すべき変更のリストです。
- FIPS のサポート。Red Hat build of OpenJDK 21 は、RHEL が FIPS モードであるかを自動的に検出し、Red Hat build of OpenJDK 21 がそのモードで動作するように自動的に設定します。この変更は、Microsoft Windows 向けの Red Hat build of OpenJDK ビルドには適用されません。
- 暗号化ポリシーのサポート。Red Hat build of OpenJDK 21 は、有効な暗号化アルゴリズムとキーサイズ制約のリストを RHEL システム設定から取得します。これらの設定コンポーネントは、トランスポート層セキュリティー (TLS) 暗号化プロトコル、証明書パス検証、および署名された JAR によって使用されます。さまざまなセキュリティープロファイルを設定して、安全性と互換性のバランスをとることができます。この変更は、Microsoft Windows 向けの Red Hat build of OpenJDK ビルドには適用されません。
-
src.zipファイルには、Red Hat build of OpenJDK に同梱されるすべての JAR ライブラリーのソースが含まれます。 - RHEL の Red Hat build of OpenJDK は、タイムゾーン情報のソースとして、システム全体のタイムゾーンデータファイルを使用します。
- RHEL の Red Hat build of OpenJDK は、システム全体の CA 証明書を使用します。
- Microsoft Windows の Red Hat build of OpenJDK には、RHEL で利用可能な最新のタイムゾーンデータが含まれています。
- Microsoft Windows 向け Red Hat build of OpenJDK は、RHEL から入手可能な最新の CA 証明書を使用します。
第3章 Red Hat build of OpenJDK 21.0.7.1 リリースノート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of OpenJDK 21.0.7.1 のパッチリリースには、次の変更が含まれています。
複数の NUMA ノードで G1 ガベージコレクターを使用する際に、リージョン割り当てで発生する可能性のある障害を修正
非均一メモリーアクセス (NUMA) システムでは、オペレーティングシステムはタスクを 1 つの NUMA ノードから別の NUMA ノードに移行することを選択できます。Garbage-First (G1) ガベージコレクターでは、G1AllocRegion オブジェクトは NUMA ノードに関連付けられています。G1Allocator コードは現在のスレッドに対してのみ G1AllocRegion オブジェクトを取得しますが、オペレーティングシステムのスケジュールにより、NUMA とスレッドの関連付けが任意に変更される可能性があります。
以前の Red Hat build of OpenJDK リリースでは、複数の NUMA ノードで G1 ガベージコレクターを使用すると、使用中の G1AllocRegion オブジェクトが操作中に変更されると、障害が発生する可能性がありました。
Red Hat build of OpenJDK 21.0.7.1 では、ある操作の全体にわたって同一の NUMA ノードと、それに関連付けられた G1AllocRegion オブジェクトが確実に使用することで、この問題を解決します。
この修正は、2025 年 7 月に予定されている次の 21.0.8 リリースにも含まれます。ただし、この修正は、NUMA デバイス上の G1 ガベージコレクターで問題が発生している可能性のあるお客様向けに早期にリリースされます。
この修正は RHEL 8 でのみ利用可能です。RHEL 8 で G1 および NUMA の問題が発生していない場合は、この修正を適用する必要はありません。
JDK-8351500 (JDK Bug System) を参照してください。
Red Hat build of OpenJDK 21.0.7.1 に関連するアドバイザリー
以下のアドバイザリーは、本リリースに含まれるバグ修正および CVE の修正に発行されています。
第4章 Red Hat build of OpenJDK の機能 リンクのコピーリンクがクリップボードにコピーされました!
最新の Red Hat build of OpenJDK 21 リリースには、新機能が含まれる可能性があります。さらに、最新リリースは、以前の Red Hat build of OpenJDK 21 リリースに由来する機能を強化、非推奨、または削除する可能性があります。
その他すべての変更点やセキュリティー修正は、OpenJDK 21.0.7 Released を参照してください。
Red Hat build of OpenJDK の機能拡張
Red Hat build of OpenJDK 21 では、以前のリリースの Red Hat build of OpenJDK で作成された機能に拡張が行われました。
削除されたファイルエントリーに関する jarsigner ツールからの警告
以前の Red Hat build of OpenJDK リリースでは、署名付き JAR ファイルからファイルが削除されたが、ファイル署名がまだ存在する場合、jarsigner ツールはこの状況を検出しませんでした。
Red Hat build of OpenJDK 21.0.7 では、jarsigner ‑verify コマンドを使用して、すべての署名に一致するファイルエントリーがあることを確認できます。不一致が存在すると、このコマンドは警告を出力します。一致しないエントリーの名前を表示するには、コマンドに ‑verbose オプションを追加します。
JDK-8309841 (JDK Bug System) を参照してください。
2025 年 4 月 15 日以降に発行され、Camerfirma ルート CA によってアンカーされた TLS サーバー証明書の信頼解除
Google、Mozilla、Apple、Microsoft が最近発表した同様の計画に従い、Red Hat build of OpenJDK 21.0.7 は、2025 年 4 月 15 日以降に発行され、Camerfirma ルート証明書によってアンカーされている TLS 証明書を信頼しません。
Red Hat build of OpenJDK は、2025 年 4 月 15 日以前に発行された証明書を、その証明書の有効期限が切れるまで引き続き信頼します。
サーバーの証明書チェーンが影響を受ける証明書によってアンカーされている場合は、TLS セッションをネゴシエートしようとすると、トラストアンカーが信頼されていないことを示す例外が発生して失敗するようになりました。以下に例を示します。
TLS server certificate issued after 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
TLS server certificate issued after 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root -
2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
次の keytool コマンドを使用して、この変更が JDK キーストア内の証明書に影響するかどうかを確認できます。
keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
この変更がチェーン内のいずれかの証明書に影響する場合は、この証明書を更新するか、証明書の管理を担当する組織に問い合わせてください。
Camerfirma ルート証明書でアンカーされた TLS サーバー証明書を引き続き使用する場合は、jdk.security.caDistrustPolicies セキュリティープロパティーから CAMERFIRMA_TLS を削除するには、java.security 設定ファイルを変更するか、java.security.properties システムプロパティーを使用します。
信頼されていない TLS サーバー証明書を引き続き使用する場合は、お客様の責任となります。
これらの制限は、Red Hat build of OpenJDK に含まれる次の Camerfirma ルート証明書に適用されます。
- 証明書 1
- エイリアス名: camerfirmachamberscommerceca [jdk]
- 識別名: CN=Chambers of Commerce Root OU=http://www.chambersign.org O=AC Camerfirma SA CIF A82743287 C=EU
- SHA256: 0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3
- 証明書 2
- エイリアス名: camerfirmachambersca [jdk]
- 識別名: CN=Chambers of Commerce Root - 2008 O=AC Camerfirma S.A.シリアル番号=A82743287 L=Madrid (see current address at www.camerfirma.com/address) C=EU
- SHA256: 06:3E:4A:FA:C4:91:DF:D3:32:F3:08:9B:85:42:E9:46:17:D8:93:D7:FE:94:4E:10:A7:93:7E:E2:9D:96:93:C0
- 証明書 3
- エイリアス名: camerfirmachambersignca [jdk]
- 識別名: CN=Global Chambersign Root - 2008 O=AC Camerfirma S.A.シリアル番号=A82743287 L=Madrid (see current address at www.camerfirma.com/address) C=EU
- SHA256: 13:63:35:43:93:34:A7:69:80:16:A0:D3:24:DE:72:28:4E:07:9D:7B:52:20:BB:8F:BD:74:78:16:EE:BE:BA:CA
JDK-8346587 (JDK Bug System) を参照してください。
PKCS11 メカニズムにおける SunPKCS11 プロバイダーのチェックの問題の修正
OpenJDK 14 では、SunPKCS11 プロバイダーによって レガシーメカニズム の概念が導入されました。メカニズムが弱いアルゴリズムを使用していると、プロバイダーはこのメカニズムがレガシーであると判断し、その後無効にします。
以前のリリースでは、この動作は柔軟性に欠けていました。たとえば、従来の決定をオーバーライドして、無効なメカニズムを有効にすることはできませんでした。また、暗号化が使用されていない場合でも、署名に使用されていたメカニズムは、暗号化アルゴリズムが弱い場合はレガシーとみなされ、無効になる可能性があります。同様に、弱い署名アルゴリズムにより、このメカニズムを暗号化または復号化の暗号として使用できませんでした。
Red Hat build of OpenJDK 21.0.7 では、SunPKCS11 プロバイダーの allowLegacy 設定プロパティーを導入することでこれらの問題を解決します。allowLegacy プロパティーを true に設定して、レガシーの決定をオーバーライドできます。このプロパティーはデフォルトで false に設定されています。
このリリース以降、プロバイダーはレガシーステータスを決定する際にサービスタイプも考慮します。プロバイダーは、暗号には暗号化アルゴリズムのみをチェックし、署名には署名アルゴリズムのみをチェックするようになりました。
JDK-8293345 (JDK Bug System) を参照してください。
第5章 このリリースに関連するアドバイザリー リンクのコピーリンクがクリップボードにコピーされました!
このリリースに含まれるバグ修正と CVE 修正を文書化するために、次のアドバイザリーが発行されます。
改訂日時: 2025-05-22