Red Hat SummitApicurio Registry 2.5 リリースノート
Red Hat build of Apicurio Registry の新機能
概要
はじめに
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック
Red Hat ドキュメントに関するご意見やご感想をお寄せください。
改善を提案するには、Jira 課題を作成し、変更案についてご説明ください。ご要望に迅速に対応できるよう、できるだけ詳細にご記入ください。
前提条件
-
Red Hat カスタマーポータルのアカウントがある。このアカウントを使用すると、Red Hat Jira Software インスタンスにログインできます。
アカウントをお持ちでない場合は、アカウントを作成するように求められます。
手順
- Create issue にアクセスします。
- Summary テキストボックスに、問題の簡単な説明を入力します。
Description テキストボックスに、次の情報を入力します。
- 問題が見つかったページの URL
-
問題の詳細情報
他のフィールドの情報はデフォルト値のままにすることができます。
- Create をクリックして、Jira 課題をドキュメントチームに送信します。
フィードバックの提供にご協力いただきありがとうございました。
第1章 Apicurio Registry 2.5 リリースノート
Red Hat build of Apicurio Registry は、Apicurio Registry オープンソースコミュニティープロジェクトをベースとする標準イベントスキーマおよび API デザインのデータストアです。
Red Hat build of Apicurio Registry は、Red Hat Integration Service Registry の新しい製品名です。Red Hat build of Apicurio Registry 2.x と Red Hat Integration Service Registry 2.x は機能的に同じです。
Apicurio Registry を使用して、Web コンソール、REST API、Maven プラグイン、または Java クライアントを使用してデータの構造を管理および共有できます。たとえば、クライアントアプリケーションは、再デプロイせずに最新のスキーマ更新を Apicurio Registry に動的にプッシュまたはプルできます。オプションのルールを作成して、Apicurio Registry のコンテンツが時間とともにどのように進化するかを管理することもできます。このルールには、コンテンツの検証、アーティファクト参照の整合性、スキーマまたは API バージョンの下位互換性または上位互換性が含まれます。
1.1. Apicurio Registry のインストールオプション
次のデータストレージオプションのいずれかを使用して、OpenShift に Apicurio Registry をインストールできます。
- PostgreSQL データベース
- Red Hat AMQ Streams
詳細は、OpenShift への Red Hat build of Apicurio Registry のインストールとデプロイ を参照してください。
1.2. Apicurio Registry がサポートするプラットフォーム
Apicurio Registry 2.5 は、次のコアプラットフォームをサポートしています。
- Red Hat OpenShift Container Platform: 4.15、4.14、4.13、4.12
- Red Hat OpenShift Service on AWS: 4.13
- Microsoft Azure Red Hat OpenShift: 4.13
- PostgreSQL: 15、14、13、12
- Red Hat AMQ Streams: 2.6、2.5、2.2
- OpenJDK: 17、11
詳細は、次の記事を参照してください。
1.2.1. 他の製品とのインテグレーションをサポート
Apicurio Registry 2.5 は、次の製品との統合もサポートしています。
- Red Hat Single Sign-On (RH-SSO) 7.6
- Red Hat build of Debezium 2.3
1.2.2. Operator メタデータのバージョン
Apicurio Registry のインストールとデプロイに使用される Service Registry Operator メタデータの対応バージョンの詳細は、次の記事を参照してください。
1.3. Apicurio Registry の新機能
Apicurio Registry 2.5 には、次の新機能が含まれています。
Apicurio Registry コアの新機能
- Quarkus 3.x へのアップグレード
- Apicurio Registry サーバーランタイムが Quarkus 2.x から Quarkus 3.x にアップグレードされました。このアップグレードにより、セキュリティー、パフォーマンス、メンテナンス性が向上します。詳細は、https://quarkus.io/quarkus3/ を参照してください。Apicurio Registry 2.5 は Quarkus 3.2 上にビルドされています。
- Avro SerDes の改善
- Apache Avro シリアライザー/デシリアライザーを使用する場合の、null フィールドを含むスキーマの生成をサポートします。詳細は、Registry-3862 を参照してください。
- スキーマキャッシュのフォールトトレランス
- スキーマキャッシュのロードが失敗した場合に、エラーを出力するのではなく、既存のスキーマキャッシュエントリーを使用するオプションを追加しました。詳細は、Registry-3807 を参照してください。
- アーティファクトコンテンツの逆参照
-
参照されたコンテンツをインラインで含むアーティファクトコンテンツを返すと役立つ場合があります。このような場合に備えて、Core Registry API v2 では、特定の操作で
dereferenceクエリーパラメーターのサポートが追加されています。詳細は、Apicurio Registry v2 コア REST API ドキュメント を参照してください。 2.5.11 より前では、このサポートは API 操作で
dereferenceパラメーターが指定されている場合に、Avro および Protobuf アーティファクトに対してのみ実装されています。このパラメーターは、他のアーティファクトタイプではサポートされません。詳細は、Registry-2865 を参照してください。注記Protobuf アーティファクトの場合、コンテンツの逆参照は、すべてのスキーマが同じパッケージに属している場合にのみサポートされます。
2.5.11 以降では、サポートが JSON スキーマ、非同期 API、OpenAPI に拡張されています。
注記JSON スキーマアーティファクトの場合、コンテンツの逆参照は、別のアーティファクトの完全なコンテンツを参照するアーティファクトに対してのみサポートされます。アーティファクトが 2 番目のアーティファクトの一部を参照する場合の逆参照は サポート対象外 です。
-
参照されたコンテンツをインラインで含むアーティファクトコンテンツを返すと役立つ場合があります。このような場合に備えて、Core Registry API v2 では、特定の操作で
- Apicurio Registry Maven プラグインの改善
-
Maven プラグインに
registerゴールをスキップするオプションを追加します。詳細は、Registry-3817 を参照してください。 pom.xmlファイルのautoRefオプションを使用して、Maven プラグインの参照を自動で検出します。詳細は、Registry-3439 を参照してください。これはテクノロジープレビューの機能です。重要テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
-
Maven プラグインに
Apicurio Registry Operator の新機能
- SQL データソース設定のサポートの改善
-
Apicurio Registry Operator は、
spec.configuration.sql.dataSourceフィールドの代わりに環境変数を使用した SQL データソースの設定をサポートします。ApicurioRegistryカスタムリソースでプレーンテキストの代わりに Kubernetes シークレットを使用して SQL 認証情報を提供できるようになりました。詳細は、https://access.redhat.com/solutions/7059053 を参照してください。 このバージョンでは、このユースケースをより適切にサポートするために Apicurio Registry Operator が改良されました。
spec.configuration.sql.dataSourceフィールドとspec.configuration.envフィールドの両方を使用して、設定の一部を定義できるようになりました。たとえば、次の設定が有効になりました。apiVersion: registry.apicur.io/v1 kind: ApicurioRegistry metadata: name: myregistry spec: configuration: persistence: sql sql: dataSource: url: "jdbc:postgresql://..." userName: "postgres-user" env: - name: REGISTRY_DATASOURCE_PASSWORD valueFrom: secretKeyRef: name: postgres-secret key: passwordまた、Operator はこのタイプの設定を検出し、ユーザーの追加介入なしで即座に適用します。
-
Apicurio Registry Operator は、
Apicurio Registry ユーザーのドキュメントおよび例
ドキュメントライブラリーは、バージョン 2.5 で利用可能な新機能で更新されました。
オープンソースのデモンストレーションアプリケーションも更新されました。
1.4. Apicurio Registry の非推奨機能
Apicurio Registry コアの非推奨機能
- Confluent Schema Registry API バージョン 6 (互換性 API): Apicurio Registry は現在、別のエンドポイントで Confluent Schema Registry API の 2 つのバージョン (バージョン 6 とバージョン 7) をサポートしています。v6 API エンドポイントは非推奨になり、今後のリリースで削除される予定です。v6 API エンドポイントへのすべての参照を v7 API エンドポイントへの参照に置き換えてください。
- Apicurio Registry Core API バージョン 1: Apicurio Registry Core API の元のバージョン (バージョン 1) に対する Apicurio Registry のサポートは廃止予定です。この v1 のレガシー API は、次のメジャーリリースで削除される予定です。
-
動的ログレベル設定:
/admin/loggersおよび/admin/loggers/{logger}API エンドポイントは、v2 Apicurio Registry Core API で非推奨になりました。これらのエンドポイントは今後のリリースで削除される予定です。 - Registry V1 エクスポートユーティリティー: Apicurio コマンドラインエクスポートユーティリティーのレジストリーサポートは廃止されました。Apicurio Registry 1.x から 2.x にインポートできる形式にデータをエクスポートするためのエクスポートツールに対する、リリースおよびメンテナンスがなくなりました。すべてのお客様はすでに 1.x から 2.x にアップグレードしているはずです。
Apicurio Registry Operator の非推奨機能
-
JAVA_OPTIONS environment variable:
JAVA_OPTIONS環境変数は、Apicurio Registry の Java オプションの設定に推奨される方法ではなくなりました。代わりにJAVA_OPTS_APPEND環境変数を使用できます。Java オプションのデフォルトの内容を置き換えるJAVA_OPTS環境変数も使用できます。ただし、一部の Apicurio Registry Operator 機能に干渉する可能性があるため、JAVA_OPTSの使用は避けることを推奨します。 -
Deployment リソースの編集による環境変数の設定: 以前のバージョンでは、Apicurio Registry Operator によってサポートされていた
Deploymentリソースを直接編集することで、Apicurio Registry の環境変数を設定できました。ApicurioRegistryCRD ファイルのspec.configuration.envフィールドを使用して環境変数を管理できるようになったため、以前の手順は非推奨となり、それに対する Operator サポートは削除されます。Operator によって設定されていないすべての環境変数を設定するには、必ずspec.configuration.envフィールドを使用してください。 - 有効になっていない機能の環境変数の保持: Apicurio Registry Operator は、Kafka ストレージ使用時の Salted Challenge Response Authentication Mechanism (SCRAM) セキュリティーなど、さまざまな機能を有効にして設定するための環境変数を設定します。このような機能が無効になっている場合、Operator は現在、関連する環境変数を保持しているため、問題が発生する可能性があります。このような環境変数の保持は非推奨となり、それに対する Operator のサポートは削除されます。このような環境変数に依存するデプロイメントは使用しないようにしてください。
-
環境変数の優先順位: Apicurio Registry Operator は、
spec.configuration.envフィールドですでに明示的に指定されている環境変数を設定しようとする場合があります。環境変数に競合する値がある場合、デフォルトでは、Apicurio Registry Operator によって設定された値が優先されます。この動作は今後変更され、Operator によって設定されたほとんどの環境変数をユーザーが上書きできるようになります。デプロイメントが元の優先動作に依存していないことを確認してください。
1.5. Apicurio Registry デプロイメントのアップグレードと移行
OpenShift では、Apicurio Registry サーバーを Apicurio Registry 2.x から Apicurio Registry 2.5 に自動的にアップグレードできます。Apicurio Registry 1.x から Apicurio Registry 2.x への自動アップグレードはなく、移行プロセスが必要です。
1.5.1. 2.x クライアントの依存関係の更新
このリリースでは、クライアントの依存関係の更新は必須ではありません。既存の Apicurio Registry 2.x クライアントアプリケーションは、引き続き Apicurio Registry 2.5 で動作します。
ただし、Apicurio Registry の次のリリースの前に、最新バージョンの Apicurio Registry を使用するようにクライアントの依存関係をすべて更新する必要があります。クライアントの依存関係には、Apicurio Registry Kafka シリアライザー/デシリアライザー (SerDes)、Maven プラグイン、および Java クライアントアプリケーションの依存関係が含まれます。
たとえば、Java クライアントアプリケーションの Maven 依存関係を更新するには、次のように pom.xml ファイルでバージョンを指定します。
<dependency>
<groupId>io.apicurio</groupId>
<artifactId>apicurio-registry-client</artifactId>
<version>2.5.11.Final-redhat-00001</version>
</dependency>詳細は、デフォルトで有効になっているレガシー REST API の日付形式 を参照してください。
1.5.2. OpenShift での Apicurio Registry 2.x からのアップグレード
OpenShift 4.11 の Apicurio Registry 2.x から OpenShift 4.12 以降の Apicurio Registry 2.5 にアップグレードできます。Apicurio Registry と OpenShift の両方のバージョンをアップグレードし、OpenShift のマイナーバージョンを 1 つずつアップグレードする必要があります。
前提条件
- OpenShift 4.11 以降に Apicurio Registry 2.x がすでにインストールされている。
既存の Apicurio Registry ストレージデータを Kafka トピックまたは PostgreSQL データベースにバックアップしている。詳細は、OpenShift への Red Hat build of Apicurio Registry のインストールとデプロイ を参照してください。
重要OpenShift の実稼働環境では、アップグレード前にストレージが確実にバックアップされるように、Apicurio Registry の Operator 更新承認ストラテジーを自動ではなく手動に設定することが推奨されます。
手順
- OpenShift Container Platform Web コンソールで、Administration をクリックしてから Cluster Settings をクリックします。
-
Channel フィールドの横にある鉛筆アイコンをクリックし、次のマイナー
candidateバージョンを選択します (たとえば、stable-4.11からcandidate-4.12に変更します)。 - Save をクリックしてから Update をクリックし、アップグレードが完了するまで待ちます。
-
OpenShift バージョンが 4.13 未満の場合は、手順 2 と 3 を繰り返して、
candidate-4.13以降を選択します。 - Operators > Installed Operators > Red Hat Integration - Service Registry をクリックします。
-
Update channel が
2.xに設定されていることを確認します。 -
Update approval が Automatic に設定されている場合は、
2.xチャネルが設定された直後にアップグレードを承認してインストールする必要があります。 - Update approval が Manual に設定されている場合は、Install をクリックします。
- Operator がデプロイされ、Apicurio Registry Pod がデプロイされるまで待ちます。
- Apicurio Registry システムが稼働中であることを確認します。
関連情報
- OpenShift Container Platform Web コンソールで Operator 更新チャネルを設定する方法の詳細は、Operator の更新チャネルの変更 を参照してください。
1.5.3. OpenShift 上の Apicurio Registry 1.1 からの移行
Apicurio Registry 1.1 から Apicurio Registry 2.x への移行の詳細は、Red Hat build of Apicurio Registry デプロイメントの移行 を参照してください。
1.6. Apicurio Registry の解決済みの問題
| 問題 | 説明 |
|---|---|
| Service Registry の認証エラーが DEBUG レベルで誤ってログに記録されます。 | |
| API に逆参照パラメーターのサポートを実装します。 |
| 問題 | 説明 |
|---|---|
| Apicurio Registry Operator は、JAVA_OPTS_APPEND 環境変数と JAVA_OPTIONS (非推奨) 環境変数の両方をサポートする必要があります。 | |
| Apicurio Registry のアップグレードにより、Confluent v6 互換性 API が破損します。 |
| 問題 | 説明 |
|---|---|
| KafkaSQL ストレージおよび参照を含む Protobuf アーティファクトを使用して Apicurio Registry をアップグレードすると、データ損失が発生する可能性があります。 | |
| Operator を 2.2.3 にアップグレードした後の CrashLoop の Apicurio Registry Pod。 | |
| Apicurio Registry から適切に削除されていない孤立したコンテンツ。 | |
| 単一のアーティファクトに対して同じ名前の 2 つの参照が作成されると、Apicurio Registry サーバーが失敗します。 | |
|
すべてのルールを削除する REST API 操作では、 | |
| フィールド順序が異なる Avro は、標準的な形式では等しいと見なされます。 | |
| 有効性、互換性、整合性ルールの値は、読み取り専用モードの Apicurio Registry Web コンソールには表示されません。 |
| 問題 | 説明 |
|---|---|
| AMQ Streams ストレージと OAuth が設定されている場合、kafka-oauth-client クラスが欠落しているため、Apicurio Registry の起動に失敗する |
| 問題 | 説明 |
|---|---|
| 一部のヘルスチェックが、カウンターが上限に達しても常に UP になる | |
| スキーマがローカルキャッシュ (SerDes) にすでに存在する場合でもスキーマレジストリーが呼び出される | |
| リソースオーナーパスワードの付与 - 基本認証 - java.lang.IllegalStateException: Client is closed | |
| Protobuf content canonicalHash outdated value detected |
1.7. Apicurio Registry が解決した CVE
次の Common Vulnerabilities and Exposures (CVE) は Apicurio Registry 2.5 で解決されています。
| CVE | 説明 |
|---|---|
| Eclipse Vert.x ツールキットの脆弱性により、Netty FastThreadLocal データ構造の使用によりメモリーリークが発生します。 | |
| Eclipse Vert.x ツールキットの脆弱性により、TLS および SNI サポートが設定された TCP サーバーでメモリーリークが発生します。 | |
| Apache Commons Compress に、制限のないリソースの割り当てやスロットリングの脆弱性が見つかりました。 | |
| Apache Common Compress に、到達不可能な終了条件を持つループ (無限ループ) の脆弱性が見つかりました。 | |
| io.netty:netty-codec-http パッケージに不具合が見つかりました。このパッケージの影響を受けるバージョンは、HttpPostRequestDecoder 内のデータが蓄積されるため、制限なしのリソース割り当てまたはスロットルに対して脆弱です。 |
| CVE | 説明 |
|---|---|
| 悪用が困難な脆弱性により、認証されていない攻撃者が複数のプロトコルを介してネットワークにアクセスし、Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition を侵害する可能性があります。 | |
| 悪用が困難な脆弱性により、権限の低い攻撃者が Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition が実行されるインフラストラクチャーにログオンし、Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition を侵害する可能性があります。 | |
| 簡単に悪用可能な脆弱性により、認証されていない攻撃者が複数のプロトコルを介してネットワークにアクセスし、Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition を侵害する可能性があります。 | |
| Libxml2 に不具合が見つかりました。この不具合には、/libxml2/SAX2.c にある xmlSAX2StartElement() 関数によるグローバルバッファーオーバーフローが含まれています。 | |
| Avahi に脆弱性が見つかりました。到達可能なアサーションが avahi_alternative_host_name() 関数に存在します。 | |
| Avahi に脆弱性が見つかりました。到達可能なアサーションが avahi_rdata_parse() 関数に存在します。 | |
| Avahi に脆弱性が見つかりました。到達可能なアサーションが dbus_set_host_name 関数に存在します。 | |
| Avahi に脆弱性が見つかりました。到達可能なアサーションが avahi_escape_label() 関数に存在します。 | |
| Avahi に脆弱性が見つかり、到達可能なアサーションが avahi_dns_packet_append_record に存在します。 | |
| 3.11.3 までの Python のメールモジュールは、特殊文字を含むメールアドレスを誤って解析します。 | |
| SQLite3 に脆弱性が見つかりました。この問題は、make alltest Handler コンポーネントの ext/session/sqlite3session.c 関数の sessionReadRecord 関数に影響を与えます。操作により、ヒープベースのバッファーオーバーフローが発生する可能性があります。 | |
| RSA-PSK ClientKeyExchange の不正な暗号文に対する応答時間が、正しい PKCS#1 v1.5 パディングを使用した暗号文の応答時間と異なるという脆弱性が見つかりました。 | |
| OpenSSL に不具合が見つかり、長い X9.42 DH キーまたはパラメーターの生成または確認が、予想よりも大幅に遅くなりました。この問題はサービス拒否につながる可能性があります。 | |
| NSS で RSA 暗号化に使用されている数値ライブラリーから、RSA 復号結果の上位ビットが 0 かどうかの情報が漏洩していることが判明しました。 | |
| OpenSSL に脆弱性が見つかりました。このセキュリティー問題は、DH_check()、DH_check_ex()、または EVP_PKEY_param_check() 関数を使用して DH キーまたは DH パラメーターをチェックするアプリケーションで長い遅延が発生する可能性があるために発生します。 | |
| plistlib.py ファイルの read_ints() 関数内の Python コア plistlib ライブラリーに脆弱性が見つかりました。 | |
| heapq モジュールの heappushpop 関数を介して、Python で use-after-free の脆弱性が見つかりました。 | |
| avahi に不具合が見つかりました。avahi Unix ソケットでのクライアント接続の終了を通知するために使用されるイベントが client_work 関数で正しく処理されないため、ローカルの攻撃者が無限ループを引き起こすことになります。 |
| 問題 | 説明 |
|---|---|
| CVE-2023-5072 JSON-java: パーサーの混乱により OOM エラーが発生する | |
| CVE-2023-31582 jose4j: 反復回数の設定がセキュアでない | |
| CVE-2023-44487 の概要: HTTP/2: 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (ラピッドリセット攻撃) からの影響を受ける | |
| CVE-2023-39410 avro: apache-avro: Apache Avro Java SDK: Avro Java SDK で信頼できないデータをデシリアライズするときのメモリー | |
| CVE-2023-4853 quarkus-vertx-http: quarkus: HTTP セキュリティーポリシーの回避 | |
| CVE-2023-39321 CVE-2023-39322 integration-service-registry-operator-container: さまざまな欠陥 | |
| CVE-2023-29409 integration-service-registry-operator-container: golang: crypto/tls: 大きな RSA キーを含む証明書チェーンの検証が遅い | |
| CVE-2023-29406 integration-service-registry-operator-container: golang: net/http: ホストヘッダーのサニタイズが不十分である | |
| CVE-2023-34462 netty: SniHandler の 16 MB の割り当てにより OutOfMemoryError が発生する | |
| CVE-2023-34455 snappy-java: チャンク長がチェックされていないと DoS が発生する | |
| CVE-2023-35116 jackson-databind: cyclic 依存関係によるサービス拒否 | |
| CVE-2023-1584 quarkus-oidc: ID とアクセストークンが認可コードフロー経由で漏洩する |
| CVE | 説明 |
|---|---|
| JSR 105 API を使用する場合、Apache Santuario - XML Security for Java の 2.2.6、2.3.4、および 3.0.3 未満のすべてのバージョンは、XML 署名が生成され、デバッグレベルのロギングが有効になっている場合に、ログファイルに秘密鍵が開示され得るという問題に対して脆弱である | |
| Java のデータ圧縮ライブラリーである snappy-java の SnappyInputStream で欠陥が検出される。この問題は、チャンク長の上限チェックが欠落した結果、チャンクサイズが大きすぎるデータを解凍するときに発生する | |
| Apache Commons Compress: 不正な形式の TAR ファイルの CPU 消費によるサービス拒否 | |
| Python 3 ssl.SSLSocket が、HTTPS サーバー、および TLS クライアント認証 (mTLS など) を使用するその他のサーバー側プロトコルの特定のインスタンスで、TLS ハンドシェイクの回避に対して脆弱である | |
| kaml でタグ付きポリモーフィズムスタイルを使用したポリモーフィックな入力を解析する際のサービス拒否 | |
| Snappy-java の shuffle 関数に、演算開始前に入力サイズをチェックしないという欠陥が発見される | |
| ncurses に、setuid アプリケーションで使用すると生じる脆弱性が発見される | |
| kaml でアンカーとエイリアスを使用して入力を解析する際にサービス拒否が発生する可能性がある | |
| netty でマルチパートデコーダを使用する場合、ディスクへのアップロードの一時保存が有効になっていると、ローカルシステムの一時ディレクトリーを介してローカル情報が開示される可能性がある | |
| GLIBC_TUNABLES 環境変数の処理中に、GNU C ライブラリーの動的ローダー ld.so でバッファーオーバーフローが検出される | |
| glibc で欠陥が発見される。まれに、gaih_inet 関数が解放されたメモリーを使用し、アプリケーションがクラッシュする | |
| glibc で欠陥が発見される。極めてまれに、getaddrinfo 関数が解放されたメモリーにアクセスし、アプリケーションがクラッシュする | |
| glibc で欠陥が発見される。getaddrinfo 関数が AF_UNSPEC アドレスファミリーで呼び出され、システムが /etc/resolv.conf 経由で no-aaaa モードで設定されている場合、2048 バイトを超える TCP 経由の DNS 応答により、関数が返すアドレスデータを通じてスタックコンテンツが開示され、クラッシュを引き起こす可能性がある |
1.8. Apicurio Registry の既知の問題
Apicurio Registry 2.5 には次の既知の問題があります。
Apicurio Registry コアの既知の問題
Registry-3413: レガシー REST API の日付形式がデフォルトで有効。
互換性を最大限に高め、Apicurio Registry の古いバージョンから簡単にアップグレードできるように、OpenAPI 標準に準拠しない日付形式が Apicurio Registry REST API で使用されています。これは古いバージョンのバグが原因です。
次の Apicurio Registry リリースの前に、すべてのクライアントアプリケーションをアップグレードして最新の Apicurio Registry クライアントバージョンを使用するようにしてください。次のリリースでは日付形式のバグが修正されるため、古いクライアントは REST API と互換性がなくなります。
REST API を OpenAPI 準拠に更新するには、この バージョンの Apicurio Registry の日付形式のバグを次のように修正します。
-
2.x クライアントの依存関係の更新 の説明に従って、すべてのクライアントアプリケーションをバージョン
2.5.11.Final-redhat-00001に更新します。 次の環境変数を、以下に示されている値に設定します。
REGISTRY_APIS_V2_DATE_FORMAT=yyyy-MM-dd'T'HH:mm:ss'Z'
IPT-814: Apicurio Registry のログアウト機能が RH-SSO 7.6 と互換性がない
RH-SSO 7.6 では、ログアウトエンドポイントで使用される redirect_uri パラメーターが非推奨になりました。詳細は、RH-SSO 7.6 アップグレードガイド を参照してください。これは非推奨であるため、RH-SSO Operator を使用して Apicurio Registry のセキュリティー保護を行っている場合は、Logout ボタンをクリックすると、Invalid parameter: redirect_uri エラーが表示されます。
回避策は、https://access.redhat.com/solutions/6980926 を参照してください。
IPT-701: CVE-2022-23221 H2 により、JNDI を介してリモートサーバーからカスタムクラスをロードできる
Apicurio Registry データが AMQ Streams に保存されている場合、H2 データベースコンソールにより、リモート攻撃者は JDBC URL を使用して任意コードを実行できます。Apicurio Registry はデフォルトでは脆弱ではなく、悪意のある設定変更が必要です。
Apicurio Registry Operator の既知の問題
Operator-42: OpenShift ルートの自動生成では、間違ったベースホスト値が使用される可能性がある
複数の routerCanonicalHostname 値が指定されている場合は、Apicurio Registry OpenShift ルートの自動生成で間違ったベースホスト値が使用される可能性があります。
付録A サブスクリプションの使用
Apicurio Registry は、ソフトウェアサブスクリプションから提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。
アカウントへのアクセス
- access.redhat.com に移動します。
- アカウントがない場合は作成します。
- アカウントにログインします。
サブスクリプションのアクティベート
- access.redhat.com に移動します。
- My Subscriptions に移動します。
- Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。
ZIP および TAR ファイルのダウンロード
ZIP または TAR ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合、この手順は必要ありません。
- ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
- Integration and Automation カテゴリーで Red Hat Integration エントリーを見つけます。
- 目的の Apicurio Registry 製品を選択します。Software Downloads ページが開きます。
- コンポーネントの Download リンクをクリックします。
改訂日時: 2024-05-30
