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

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

このトピックには、パッケージグループの定義、パターンマッチング動作、パッケージの関連付け強度、パッケージグループ階層に関する情報が含まれます。

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

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

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

使用できる各組み合わせのパターン例を以下に示します。

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

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

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

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

名前空間を含まないパッケージまたはパッケージ形式の場合 (Python および NuGet)、パッケージグループに名前空間を含めることはできません。これらのパッケージグループのパッケージグループ定義には、空白の名前空間セクションが含まれています。例えば、requests という名前の 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 つのグループだけであり、それは最も特異的に一致するグループです。

パッケージパスが複数のパターンに一致する場合、より「特異的」なパターンとは、最長一致するパターンと考えることができます。別の言い方をすると、より特異的なパターンとは、より一般的なパターンに一致するパッケージのうち、真部分集合にだけ一致するパターンを指します。前の例では、/npm/space/* に一致するすべてのパッケージが /npm/* とも一致しますが、その逆は成り立ちません。つまり、/npm/space/* は、/npm/* の真部分集合であるため、より特異的なパターンになります。一方のグループがもう一方のグループの部分集合である場合、そこには階層が生じ、/npm/space/* は親グループである /npm/* のサブグループとなります。

パッケージには最も特異的なパッケージグループの設定のみが適用されますが、そのグループが親グループの設定を継承するように構成されている場合もあります。

単語、単語境界、プレフィックスマッチング

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

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

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

以上のように単語と単語境界を定義したので、CodeArtifact のプレフィックスマッチングについて説明できます。単語境界のプレフィックスの一致を示すために、単語文字の後に一致文字 (~) が使用されます。例えば、パターン /npm/space/foo~ は、パッケージパス /npm/space/foo と /npm/space/foo-bar に一致しますが、/npm/space/food と /npm/space/foot には一致しません。

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

大文字と小文字の区別

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

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

強い一致と弱い一致

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

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

その他のバリエーション

大文字と小文字の違いに加えて、弱い一致では、ダッシュ (-)、ドット (.)、アンダースコア (_)、および紛らわしい文字 (別のアルファベットに見た目が似ている文字など) の並びの違いも無視されます。弱い一致に使用される正規化の際に、CodeArtifact は大文字小文字の畳み込み (小文字への変換と同様) を実行し、ダッシュ、ドット、アンダースコアの文字の並びを 1 つのドットに置き換え、混同されやすい文字を正規化します。

弱い一致では、ダッシュ、ドット、アンダースコアは同等に扱われますが、完全に無視されることはありません。つまり、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 と混同される可能性があります。