パッケージグループ定義の構文と一致動作 - CodeArtifact
パッケージグループ定義の構文と例パッケージグループの階層とパターンの仕様単語、単語の境界、プレフィックスの一致大文字と小文字の区別強力な対戦と弱い対戦その他のバリエーション

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

パッケージグループ定義の構文と一致動作

このトピックでは、パッケージグループ、パターンマッチング動作、パッケージ関連付けの強度、およびパッケージグループ階層の定義について説明します。

パッケージグループ定義の構文と例

パッケージグループを定義するためのパターン構文は、パッケージパスの形式に厳密に従います。パッケージパスは、パッケージの調整コンポーネント (形式、名前空間、名前) から作成されます。そのためには、先頭にスラッシュを追加し、各コンポーネントをスラッシュで区切ります。例えば、名前空間anycompany-ui-componentsの という名前の npm パッケージのパッケージパスは /npm/space/ anycompany-ui-componentsです。

パッケージグループパターンは、パッケージパスと同じ構造に従います。ただし、グループ定義の一部として指定されていないコンポーネントは省略され、パターンはサフィックスで終了します。含まれるサフィックスによって、次のようにパターンの一致動作が決まります。

  • $ サフィックスは完全なパッケージ座標と一致します。

  • ~ サフィックスはプレフィックスと一致します。

  • * サフィックスは、以前に定義したコンポーネントのすべての値と一致します。

許可される各組み合わせのパターンの例を次に示します。

  1. すべてのパッケージ形式: /*

  2. 特定のパッケージ形式: /npm/*

  3. パッケージ形式と名前空間プレフィックス: /maven/com.anycompany~

  4. パッケージ形式と名前空間: /npm/space/*

  5. パッケージ形式、名前空間、名前プレフィックス: /npm/space/anycompany-ui~

  6. パッケージ形式、名前空間、名前: /maven/org.apache.logging.log4j/log4j-core$

上記の例に示すように、プレフィックスの一致を表すために~サフィックスが名前空間または名前の末尾に追加され、パス内の次のコンポーネントのすべての値 (すべての形式、すべての名前空間、またはすべての名前) と一致するために使用されると、スラッシュの後に*付加されます。

パッケージグループの定義と正規化

CodeArtifact は NuGet、、Python、および Swift パッケージ名を正規化し、Swift パッケージ名前空間を保存する前に正規化します。 は、パッケージグループ定義でパッケージを照合するときに、これらの正規化された名前 CodeArtifact を使用します。したがって、これらの形式で名前空間または名前を含むパッケージグループは、正規化された名前空間と名前を使用する必要があります。パッケージ名と名前空間の正規化方法の詳細については、、Python NuGet、および Swift 名の正規化ドキュメントを参照してください。

パッケージグループ定義の名前空間

名前空間 (Python および NuGet) のないパッケージまたはパッケージ形式の場合、パッケージグループに名前空間を含めることはできません。これらのパッケージグループのパッケージグループ定義には、空白の名前空間セクションが含まれています。例えば、リクエストという名前の Python パッケージのパスは /python//requests です。

名前空間 (Maven、汎用、Swift) を持つパッケージまたはパッケージ形式の場合、パッケージ名が含まれている場合は名前空間を含める必要があります。Swift パッケージ形式には、正規化されたパッケージ名前空間が使用されます。Swift パッケージ名前空間の正規化方法の詳細については、「」を参照してくださいSwift パッケージ名と名前空間の正規化。

パッケージグループの階層とパターンの仕様

パッケージグループが「入力」または「関連付け」されているパッケージは、グループのパターンに一致するが、より具体的なグループのパターンと一致しないパッケージパスを持つパッケージです。例えば、パッケージグループ /npm/*と の場合/npm/space/*、パッケージパス /npm//react は最初のグループ (/npm/*) に関連付けられ、/npm/space/aui.components と /npm/space/ amplify-ui-coreは 2 番目のグループ () に関連付けられます/npm/space/*。パッケージは複数のグループと一致する場合がありますが、各パッケージは 1 つのグループにのみ関連付けられ、最も具体的な一致は 1 つのグループの設定のみがパッケージに適用されます。

パッケージパスが複数のパターンに一致する場合、「より具体的な」パターンは最も長い一致パターンと考えることができます。または、より具体的なパターンは、より具体的なパターンに一致するパッケージの適切なサブセットに一致するパターンです。前の例から、一致するすべてのパッケージは /npm/space/*と一致しますが/npm/*、逆の場合は true ではないため、 の適切なサブセットであるため、/npm/space/*より具体的なパターンになります/npm/*。1 つのグループは別のグループのサブセットであるため、階層を作成します。階層 は親グループ のサブグループ/npm/space/*です/npm/*。

最も具体的なパッケージグループの設定のみがパッケージに適用されますが、そのグループは親グループの設定から継承するように設定できます。

単語、単語の境界、プレフィックスの一致

プレフィックスマッチングについて説明する前に、いくつかの重要な用語を定義しましょう。

  • 文字または数字の後に 0 個以上の文字、数字、またはマーク文字 (数字、凡例など) が続く単語。

  • 単語以外の文字に達した場合、単語の境界は単語の末尾にあります。単語以外の文字は、.、、 などの句読点文字-です_。

具体的には、単語の正規表現パターンは であり[\p{L}\p{N}][\p{L}\p{N}\p{M}]*、次のように分類できます。

  • \p{L} は任意の文字を表します。

  • \p{N} は任意の数値を表します。

  • \p{M} は、カプセル、虹彩などのマーク文字を表します。

したがって、 [\p{L}\p{N}]は数字または文字を表し、 は 0 個以上の文字、数字、またはマーク文字[\p{L}\p{N}\p{M}]*を表し、単語境界はこの正規表現パターンの各一致の最後にあります。

注記

単語境界マッチングは、この「単語」の定義に基づいています。ディクショナリで定義されている単語、または に基づいていません CameCase。例えば、 onewordまたは に単語境界はありませんOneWord。

単語と単語の境界が定義されたので、それらを使用して でのプレフィックス一致を記述できます CodeArtifact。単語境界のプレフィックス一致を示すには、単語文字の後に一致文字 (~) を使用します。例えば、パターン はパッケージパス /npm/space/fooおよび に一致しますが/npm/space/foo-bar、 /npm/space/foodまたは には/npm/space/foo~一致しません/npm/space/foot。

パターン のように単語以外の文字に従う~場合は、 の代わりにワイルドカード (*) を使用する必要があります/npm/*。

大文字と小文字の区別

パッケージグループ定義では大文字と小文字が区別されます。つまり、大文字と小文字だけが異なるパターンは、個別のパッケージグループとして存在できます。例えば、ユーザーは、npm Public Registry に存在する 3 つの個別のパッケージ/npm//asyncstorage$のパターン /npm//AsyncStorage$、/npm//asyncStorage$、および を持つ個別のパッケージグループを作成できます。AsyncStorage、asyncStorage、大文字と小文字だけが異なる非同期です。

大文字と小文字は重要ですが、パッケージに大文字と小文字が異なるパターンのバリエーションがある場合は、パッケージをパッケージグループに CodeArtifact 関連付けます。ユーザーが上記の他の 2 つのグループを作成せずに/npm//AsyncStorage$パッケージグループを作成した場合、asyncStorage や asyncstorage AsyncStorageなど、名前 の大文字と小文字の違いはすべてパッケージグループに関連付けられます。 ただし、次のセクション「」で説明するように強力な対戦と弱い対戦、これらのバリエーションはAsyncStorageパターンと完全に一致する とは異なる方法で処理されます。

強力な対戦と弱い対戦

前のセクション の情報は大文字と小文字の区別、パッケージグループが大文字と小文字を区別し、大文字と小文字を区別しないことを示すものです。これは、 のパッケージグループ定義に強力な一致 (または完全一致) と弱い一致 (またはバリエーション一致) という概念 CodeArtifact があるためです。強力な一致は、パッケージがパターンと完全に一致し、バリエーションがない場合です。弱い一致とは、パッケージが異なる文字の大文字と小文字など、パターンのバリエーションと一致する場合です。弱い一致動作により、パッケージグループのパターンのバリエーションであるパッケージがより一般的なパッケージグループにロールアップするのを防ぐことができます。パッケージが、最も具体的な一致グループのパターンのバリエーション (一致が悪い) である場合、パッケージはグループに関連付けられますが、グループのオリジンコントロール設定を適用する代わりにパッケージがブロックされ、パッケージの新しいバージョンがアップストリームからプルされたり公開されたりするのを防ぎます。この動作により、ほぼ同じ名前のパッケージの依存関係の混同に起因するサプライチェーン攻撃のリスクが軽減されます。

弱い一致動作を説明するために、パッケージグループが取り込み/npm/*を許可し、公開をブロックするとします。より具体的なパッケージグループ は/npm//anycompany-spicy-client$、取り込みをブロックして公開を許可するように設定されています。という名前のパッケージanycompany-spicy-clientは、パッケージグループの強力な一致です。これにより、パッケージバージョンを公開でき、パッケージバージョンの取り込みがブロックされます。公開できるパッケージ名の大文字と小文字は のみです。これはanycompany-spicy-client、パッケージ定義パターンと強く一致するためです。AnyCompany-spicy-client など、別の大文字と小文字のバリエーションは、弱い一致であるため、公開がブロックされます。さらに重要なのは、パッケージグループは、パターンで使用される小文字の名前だけでなく、すべてのケースのバリエーションの取り込みをブロックし、依存関係混同攻撃のリスクを減らします。

その他のバリエーション

大文字と小文字の違いに加えて、弱い一致では、ダッシュ -、ドット .、アンダースコア _、および難読化可能な文字 (アルファベットが似たような文字) のシーケンスの違いも無視されます。弱い一致に使用される正規化中に、 は大文字と小文字の変換 (小文字への変換と同様) CodeArtifact を実行し、ダッシュ、ドット、アンダースコアの文字のシーケンスを単一のドットに置き換え、難読化可能な文字を正規化します。

弱い一致では、ダッシュ、ドット、アンダースコアは同等ですが、完全には無視されません。つまり、foo-bar 、foo.bar 、foo..bar 、foo_bar はすべて弱い一致ですが、foobar は一致しません。いくつかのパブリックリポジトリでは、これらの種類の変数を防ぐ手順が実装されていますが、パブリックリポジトリによって提供される保護では、パッケージグループのこの機能は必要ありません。例えば、npm Public Registry レジストリなどのパブリックリポジトリは、my-package が既に公開されている場合にのみ、my-package という名前のパッケージの新しいバリエーションを防止します。my-package が内部パッケージで、パッケージグループ/npm//my-package$が作成されて公開とブロックが取り込まれる場合、my.package などのバリアントが許可されないようにするために、my-package を npm Public Registry に公開したくない可能性があります。

Maven などの一部のパッケージ形式はこれらの文字を異なる方法で扱いますが (Maven は -または ではなく名前空間階層区切り文字.として扱います_）、com.act-on のようなものは com.act.on と混同される可能性があります。

注記

複数のバリエーションがパッケージグループに関連付けられている場合、管理者は特定のバリエーションの新しいパッケージグループを作成して、そのバリエーションに対して異なる動作を設定できることに注意してください。