套件群組定義語法和比對行為 - 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 會使用這些標準化名稱。因此,包含這些格式的命名空間或名稱的套件群組必須使用標準化命名空間和名稱。如需有關套件名稱和命名空間如何標準化的詳細資訊,請參閱 NuGetPython Swift 名稱標準化文件。

套件群組定義中的命名空間

對於沒有命名空間 (Python 和 NuGet) 的套件或套件格式,套件群組不得包含命名空間。這些套件群組的套件群組定義包含空白命名空間區段。例如,名為 請求的 Python 套件路徑為 /python//requests

對於具有命名空間 (Maven、一般和 Swift) 的套件或套件格式,如果包含套件名稱,則必須包含命名空間。對於 Swift 套件格式,將使用標準化套件命名空間。如需如何標準化 Swift 套件命名空間的詳細資訊,請參閱 Swift 套件名稱和命名空間標準化

套件群組階層和模式特異性

“in” 或 “associated with” 套件群組的套件是具有符合群組模式但不符合更特定群組模式之套件路徑的套件。例如,由於套件群組 /npm/*/npm/space/*,套件路徑 /npm//react 與第一個群組 (/npm/*) 相關聯,而 /npm/space/aui.components/npm/space/amplify-ui-core 與第二個群組 (/npm/space/*) 相關聯。即使套件可能符合多個群組,每個套件都只會與單一群組相關聯,是最具體的相符項目,而且只有一個群組的組態會套用至套件。

當套件路徑符合多個模式時,可將「更具體」模式視為最長的相符模式。或者,更具體的模式是與符合較不具體模式的套件的適當子集相符的模式。從我們先前的範例中,每個相符的套件/npm/space/*也都符合 /npm/*,但反向不正確,這使得模式/npm/space/*更具體,因為它是 的適當子集/npm/*。由於一個群組是另一個群組的子集,因此會建立階層,其中 /npm/space/* 是父群組的子群組 /npm/*

雖然只有最具體的套件群組組態適用於套件,但該群組可設定為繼承其父群組的組態。

字詞、字詞界限和字首比對

在討論字首比對之前,讓我們先定義一些關鍵術語:

  • 字母或數字後跟零個或更多字母、數字或標記字元 (例如重音、跛行等) 的單字

  • 當達到非單字字元時,單字邊界位於單字結尾。非單字字元是標點符號字元.,例如 -、 和 _

具體而言,單字的 regex 模式為 [\p{L}\p{N}][\p{L}\p{N}\p{M}]*,可依下列方式細分:

  • \p{L} 代表任何字母。

  • \p{N} 代表任何數字。

  • \p{M} 代表任何標記字元,例如重音、跛行等。

因此, [\p{L}\p{N}] 代表數字或字母,並[\p{L}\p{N}\p{M}]*代表零個或多個字母、數字或標記字元,且單字邊界位於此 regex 模式的每個相符項目的結尾。

注意

單字邊界比對是以「單字」的定義為基礎。它不是以字典或 中定義的單字為基礎 CameCase。例如,在 oneword或 中沒有單字邊界OneWord

現在定義了單字和單字邊界,我們可以使用它們來描述 中相符的字首 CodeArtifact。若要在單字邊界上指示字首相符,則將在單字字元之後使用相符字元 (~)。例如, 模式/npm/space/foo~符合套件路徑 /npm/space/foo/npm/space/foo-bar,但不符合 /npm/space/food/npm/space/foot

必須使用萬用字元 (*),而不是在遵循非單字字元~時,例如在模式 中/npm/*

區分大小寫

套件群組定義區分大小寫,這表示僅因大小寫而異的模式可以作為單獨的套件群組存在。例如,使用者可以/npm//asyncstorage$為 npm Public Registry 上存在的三個不同套件,建立具有模式 /npm//AsyncStorage$/npm//asyncStorage$和 的個別套件群組:AsyncStorageasyncStorage、非同步儲存,其差異僅因案例而異。

雖然大小寫很重要,但如果套件的模式因大小寫而異, CodeArtifact 仍然會將套件與套件群組建立關聯。如果使用者在不建立上述其他兩個群組的情況下建立/npm//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 公開登錄檔登錄檔等公有儲存庫,只有在 my-package 已發佈時,才會阻止名為 my-package 的套件出現新的變化。 如果 my-package 是允許/npm//my-package$發佈和封鎖擷取的內部套件和套件群組,您可能不想將 my-package 發佈到 npm Public Registry,以防止 my.package 等變體被允許。

雖然 Maven 等某些套件格式會以不同方式處理這些字元 (Maven 將 .視為命名空間階層分隔符號,但不會視為 -_),但 com.act-on 這類的物件仍可能會與 com.act.on 混淆。

注意

請注意,每當多個變化與套件群組相關聯時,管理員可以為特定變化建立新的套件群組,以設定該變化的不同行為。