기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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

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

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

패키지 그룹을 정의하기 위한 패턴 구문은 패키지 경로의 형식을 매우 따릅니다. 패키지 경로는 시작 부분에 포워드 슬래시를 추가하고 각 구성 요소를 포워드 슬래시로 분리하여 패키지의 좌표 구성 요소(형식, 네임스페이스 및 이름)에서 생성됩니다. 예를 들어 네임스페이스 공간에 이름이 지정된 npm 패키지anycompany-ui-components의 패키지 경로는 /npm/space/anycompany-ui-components입니다.

패키지 그룹 패턴은 그룹 정의의 일부로 지정되지 않은 구성 요소가 생략되고 패턴이 접미사로 종료되는 것을 제외하고 패키지 경로와 동일한 구조를 따릅니다. 포함된 접미사는 다음과 같이 패턴의 일치 동작을 결정합니다.

다음은 허용되는 각 조합의 예제 패턴입니다.

위 예제에서 볼 수 있듯이 ~ 접미사는 네임스페이스 또는 이름 끝에 추가되어 접두사 일치를 나타내며 경로의 다음 구성 요소(모든 형식, 모든 네임스페이스 또는 모든 이름)에 대한 모든 값과 일치시키는 데 사용되는 경우 슬래시 뒤에 * 표시됩니다.

패키지 그룹 정의 및 정규화

CodeArtifact 는 NuGet, Python 및 Swift 패키지 이름을 정규화하고 Swift 패키지 네임스페이스를 저장하기 전에 정규화합니다. 는 패키지를 패키지 그룹 정의와 일치시킬 때 이러한 정규화된 이름을 CodeArtifact 사용합니다. 따라서 이러한 형식의 네임스페이스 또는 이름이 포함된 패키지 그룹은 정규화된 네임스페이스 및 이름을 사용해야 합니다. 패키지 이름 및 네임스페이스가 정규화되는 방법에 대한 자세한 내용은 NuGet, Python 및 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/*.

가장 구체적인 패키지 그룹의 구성만 패키지에 적용되지만 해당 그룹은 상위 그룹의 구성에서 상속되도록 구성될 수 있습니다.

단어, 단어 경계 및 접두사 일치

접두사 일치에 대해 논의하기 전에 몇 가지 주요 용어를 정의해 보겠습니다.

특히 단어의 정규식 패턴은 이며 [\p{L}\p{N}][\p{L}\p{N}\p{M}]*다음과 같이 분류할 수 있습니다.

따라서 [\p{L}\p{N}]는 숫자 또는 문자를 나타내고 는 0개 이상의 문자, 숫자 또는 마크 문자를 [\p{L}\p{N}\p{M}]* 나타내며 단어 경계는 이 정규식 패턴의 각 일치의 끝에 있습니다.

이제 단어 및 단어 경계가 정의되었으므로 이를 사용하여 에서 접두사 일치를 설명할 수 있습니다 CodeArtifact. 단어 경계에 접두사 일치를 나타내기 위해 단어 뒤에 일치 문자(~)가 사용됩니다. 예를 들어 패턴은 패키지 경로 /npm/space/foo 및 와 /npm/space/foo~ 일치하지/npm/space/foo-bar만 /npm/space/food 또는 는 일치하지 않습니다/npm/space/foot.

패턴 에서와 같이 단어가 아닌 문자를 따르는 ~ 경우 대신 와일드카드(*)를 사용해야 합니다/npm/*.

대소문자 구분

패키지 그룹 정의는 대/소문자를 구분합니다. 즉, 대/소문자별로 다른 패턴이 별도의 패키지 그룹으로 존재할 수 있습니다. 예를 들어 사용자는 npm 퍼블릭 레지스트리에 있는 세 개의 개별 패키지/npm//AsyncStorage$에 /npm//asyncstorage$ 대해 패턴 /npm//asyncStorage$, , 를 사용하여 개별 패키지 그룹을 생성할 수 있습니다. AsyncStorage, asyncStorage, 비동기화는 사례별로 다릅니다.

사례가 중요하지만 패키지의 패턴이 사례별로 다른 경우 는 패키지를 패키지 그룹에 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와 같은 변형이 허용되지 않도록 하기 위해 my-package를 npm Public Registry에 게시하고 싶지 않을 수 있습니다.

Maven과 같은 일부 패키지 형식은 이러한 문자를 다르게 취급하지만(Maven은 네임스페이스 계층 구분자로 취급하지만 - 또는 .는 취급하지 않음_), com.act-on과 같은 것은 여전히 com.act.on과 혼동될 수 있습니다.