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

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

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

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

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

패키지 그룹을 정의하기 위한 패턴 구문은 패키지 경로의 형식을 거의 따릅니다. 패키지 경로는 시작 부분에 슬래시를 추가하고 각 구성 요소를 슬래시로 구분하여 패키지의 좌표 구성 요소 (형식, 네임스페이스, 이름) 에서 생성됩니다. 예를 들어 네임스페이스 공간에 이름이 지정된 npm 패키지의 패키지 경로는 /npm/space/입니다 anycompany-ui-components. 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 Python 및 Swift 패키지 이름을 NuGet 정규화하고 Swift 패키지 네임스페이스를 저장하기 전에 정규화합니다. CodeArtifact 패키지를 패키지 그룹 정의와 일치시킬 때 이러한 정규화된 이름을 사용합니다. 따라서 이러한 형식의 네임스페이스나 이름을 포함하는 패키지 그룹은 정규화된 네임스페이스와 이름을 사용해야 합니다. 패키지 이름과 네임스페이스가 정규화되는 방법에 대한 자세한 내용은, NuGetPythonSwift 이름 정규화 설명서를 참조하십시오.

패키지 그룹 정의의 네임스페이스

네임스페이스가 없는 패키지 또는 패키지 형식 (Python 및 NuGet) 의 경우 패키지 그룹은 네임스페이스를 포함할 수 없습니다. 이러한 패키지 그룹의 패키지 그룹 정의에는 빈 네임스페이스 섹션이 포함됩니다. 예를 들어, 요청이라는 이름의 Python 패키지의 경로는 /python//requests입니다.

네임스페이스가 있는 패키지 또는 패키지 형식 (Maven, generic, Swift) 의 경우 패키지 이름이 포함된 경우 네임스페이스를 포함해야 합니다. Swift 패키지 형식의 경우 정규화된 패키지 네임스페이스가 사용됩니다. Swift 패키지 네임스페이스의 정규화 방법에 대한 자세한 내용은 을 참조하십시오. Swift 패키지 이름 및 네임스페이스 정규화

패키지 그룹 계층 및 패턴 특이성

패키지 그룹에 “내부” 또는 “관련”인 패키지는 패키지 경로가 그룹의 패턴과 일치하지만 더 구체적인 그룹의 패턴과는 일치하지 않는 패키지입니다. 예를 들어, 패키지 /npm/* 그룹과 /npm/space/* 이 지정된 경우 패키지 경로 /npm//react는 첫 번째 그룹 (/npm/*) 에 연결되고 /npm/space/aui.compones와 /npm/space/는 두 번째 그룹 () 에 연결됩니다. amplify-ui-core /npm/space/* 패키지가 여러 그룹과 일치할 수 있지만 각 패키지는 가장 구체적으로 일치하는 단일 그룹에만 연결되며 해당 그룹의 구성만 패키지에 적용됩니다.

패키지 경로가 여러 패턴과 일치하는 경우 “더 구체적인” 패턴을 가장 오래 일치하는 패턴으로 간주할 수 있습니다. 또는 덜 구체적인 패턴과 일치하는 패키지의 적절한 하위 집합과 일치하는 패턴을 더 구체적인 패턴으로 만들 수도 있습니다. 이전 예제에서는 일치하는 모든 /npm/space/* 패키지도 일치하지만 그 반대의 경우는 그렇지 않습니다. 즉, 올바른 하위 집합이기 때문에 더 구체적인 패턴을 만들 /npm/space/* 수 있습니다. /npm/* /npm/* 한 그룹이 다른 그룹의 하위 집합이기 때문에 상위 그룹의 하위 그룹인 /npm/space/* 계층 구조가 생성됩니다. /npm/*

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

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

접두사 매칭을 설명하기 전에 몇 가지 주요 용어를 정의해 보겠습니다.

  • 단어: 문자 또는 숫자 뒤에 0개 이상의 문자, 숫자 또는 표시 문자 (예: 악센트, 움라우트 등) 가 오는 단어.

  • 단어 경계는 단어가 아닌 문자에 도달했을 때 단어 끝에 있습니다. 단어 이외의 문자는,, 와 같은 . 문장 부호 문자입니다. - _

구체적으로, 단어의 정규식 패턴은 다음과 [\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}]* 나타내며 0개 이상의 문자, 숫자 또는 표시 문자를 나타내며 단어 경계는 이 정규식 패턴과 일치하는 각 항목의 끝에 있습니다.

참고

단어 경계 매칭은 이러한 “단어” 정의를 기반으로 합니다. 사전에 정의된 단어 또는 다른 단어를 기반으로 하지 않습니다 CameCase. 예를 들어, oneword 또는 에는 단어 경계가 없습니다OneWord.

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

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

대소문자 구분

패키지 그룹 정의는 대소문자를 구분합니다. 즉, 대소문자만 다른 패턴이 별도의 패키지 그룹으로 존재할 수 있습니다. 예를 들어 사용자는 패턴을 /npm//AsyncStorage$ 사용하여 별도의 패키지 그룹을 만들 수 있으며 npm Public Registry에 있는 세 개의 개별 패키지 (AsyncStorage AsyncStorage, 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는 모두 약한 매칭이지만 foo_bar는 그렇지 않습니다. 여러 퍼블릭 리포지토리가 이러한 유형의 변형을 방지하는 단계를 구현하긴 하지만, 퍼블릭 리포지토리가 제공하는 보호 기능으로 인해 패키지 그룹의 이 기능이 불필요하지는 않습니다. 예를 들어 npm Public Registry 레지스트리와 같은 공용 리포지토리는 my-package가 이미 게시된 경우에만 my-package라는 이름의 패키지의 새로운 변형을 방지합니다. my-package가 내부 패키지이고 게시를 허용하고 수집을 차단하는 패키지 그룹이 생성된 경우 my.package와 같은 /npm//my-package$ 변형이 허용되지 않도록 하기 위해 my-package를 npm Public Registry에 게시하고 싶지 않을 것입니다.

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

참고

참고로 패키지 그룹에 여러 변형이 연결될 때마다 관리자는 특정 변형에 대해 새 패키지 그룹을 만들어 해당 변형에 대해 다른 동작을 구성할 수 있습니다.