패키지 그룹 정의 구문 및 매칭 동작

이 주제에는 패키지 그룹 정의, 패턴 일치 동작, 패키지 연결 강도 및 패키지 그룹 계층 구조에 대한 정보가 포함되어 있습니다.

패키지 그룹 정의 구문 및 예제

패키지 그룹을 정의하기 위한 패턴 구문은 패키지 경로의 형식을 밀접하게 따릅니다. 패키지 경로는 시작 부분에 슬래시를 추가하고 각 구성 요소를 슬래시로 구분하여 패키지의 좌표 구성 요소(형식, 네임스페이스 및 이름)에서 생성됩니다. 예를 들어 네임스페이스 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는 두 번째 그룹(/npm/space/*)과 연결됩니다. 패키지가 여러 그룹과 일치할 수 있지만 각 패키지는 가장 구체적으로 일치하는 단일 그룹과만 연결되며 한 그룹의 구성만 패키지에 적용됩니다.

패키지 경로가 여러 패턴과 일치하면 “보다 구체적인” 패턴을 가장 긴 일치 패턴으로 생각할 수 있습니다. 또는 보다 구체적인 패턴은 덜 구체적인 패턴과 일치하는 패키지의 적절한 하위 집합과 일치하는 패턴입니다. 이전 예제에서 /npm/space/*와 일치하는 모든 패키지는 /npm/*와도 일치하지만 그 반대는 true가 아니며, /npm/*의 적절한 하위 집합이므로 /npm/space/*을 보다 구체적인 패턴으로 만듭니다. 한 그룹은 다른 그룹의 하위 집합이므로 /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 퍼블릭 레지스트리에 있으며 대소문자만 다른 세 개의 개별 패키지인 AsyncStorage, asyncStorage, asyncstorage에 대해 /npm//AsyncStorage$, /npm//asyncStorage$ 및 /npm//asyncstorage$ 패턴을 사용하여 별도의 패키지 그룹을 생성할 수 있습니다.

대소문자가 중요하지만 패키지에 대소문자별로 다른 패턴의 변형이 있는 경우 CodeArtifact는 여전히 패키지를 패키지 그룹에 연결합니다. 사용자가 위에 표시된 다른 두 그룹을 생성하지 않고 /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과 혼동될 수 있습니다.