Syntaxe de définition du groupe de packages et comportement de correspondance

Cette rubrique contient des informations sur la définition des groupes de packages, le comportement de correspondance des modèles, la force des associations de packages et la hiérarchie des groupes de packages.

Table des matières

• Syntaxe et exemples de définition de groupes de packages
  • Définition et normalisation des groupes de packages
  • Espaces de noms dans les définitions de groupes de packages
• Hiérarchie des groupes de packages et spécificité du modèle
• Mots, limites de mots et correspondance de préfixes
• Sensibilité à la casse
• Match fort et faible
• Variations supplémentaires

Syntaxe et exemples de définition de groupes de packages

La syntaxe du modèle pour définir les groupes de packages suit de près le formatage des chemins de package. Le chemin d'un package est créé à partir des coordonnées d'un package (format, espace de noms et nom) en ajoutant une barre oblique au début et en séparant chacun des composants par une barre oblique. Par exemple, le chemin du package npm nommé anycompany-ui-componentsdans l'espace de noms est /npm/space/. anycompany-ui-components

Un modèle de groupe de packages suit la même structure qu'un chemin de package, sauf que les composants qui ne sont pas spécifiés dans le cadre de la définition du groupe sont omis et que le modèle se termine par un suffixe. Le suffixe inclus détermine le comportement correspondant du modèle, comme suit :

• Un $ suffixe correspondra aux coordonnées complètes du colis.

• Un ~ suffixe correspondra à un préfixe.

• Un * suffixe correspondra à toutes les valeurs du composant défini précédemment.

Voici des exemples de modèles pour chacune des combinaisons autorisées :

1. Tous les formats de package : /*

2. Un format de package spécifique : /npm/*

3. Format du package et préfixe d'espace de noms : /maven/com.anycompany~

4. Format du package et espace de noms : /npm/space/*

5. Format du package, espace de noms et préfixe de nom : /npm/space/anycompany-ui~

6. Format, espace de noms et nom du package : /maven/org.apache.logging.log4j/log4j-core$

Comme le montrent les exemples ci-dessus, le ~ suffixe est ajouté à la fin d'un espace de noms ou d'un nom pour représenter une correspondance de préfixe et * vient après une barre oblique lorsqu'il est utilisé pour correspondre à toutes les valeurs du composant suivant dans le chemin (tous les formats, tous les espaces de noms ou tous les noms).

Définition et normalisation des groupes de packages

CodeArtifact normalise les NuGet noms de packages Python et Swift, et normalise les espaces de noms de packages Swift avant de les stocker. CodeArtifact utilise ces noms normalisés lors de la mise en correspondance de packages avec des définitions de groupes de packages. Par conséquent, les groupes de packages contenant un espace de noms ou un nom dans ces formats doivent utiliser l'espace de noms et le nom normalisés. Pour plus d'informations sur la façon dont les noms de packages et les espaces de noms sont normalisés, consultez la NuGetdocumentation de normalisation des noms Python et Swift.

Espaces de noms dans les définitions de groupes de packages

Pour les packages ou les formats de packages sans espace de noms (Python et NuGet), les groupes de packages ne doivent pas contenir d'espace de noms. La définition du groupe de packages pour ces groupes de packages contient une section d'espace de noms vide. Par exemple, le chemin du package Python nommé requests est /python//requests.

Pour les packages ou les formats de package dotés d'un espace de noms (Maven, generic et Swift), l'espace de noms doit être inclus si le nom du package est inclus. Pour le format de package Swift, l'espace de noms de package normalisé sera utilisé. Pour plus d'informations sur la façon dont les espaces de noms des packages Swift sont normalisés, consultez. Normalisation rapide du nom du package et de l'espace de noms

Hiérarchie des groupes de packages et spécificité du modèle

Les packages « inclus » ou « associés à » un groupe de packages sont des packages dont le chemin de package correspond au modèle du groupe mais ne correspond pas au modèle d'un groupe plus spécifique. Par exemple, étant donné les groupes de packages /npm/* et/npm/space/*, le chemin du package /npm//react est associé au premier groupe (/npm/*) tandis que /npm/space/aui.components et /npm/space/ sont associés au second groupe (). amplify-ui-core /npm/space/* Même si un package peut correspondre à plusieurs groupes, chaque package n'est associé qu'à un seul groupe, la correspondance la plus spécifique, et seule la configuration de ce groupe s'applique au package.

Lorsqu'un chemin de package correspond à plusieurs modèles, le modèle « plus spécifique » peut être considéré comme le modèle correspondant le plus long. Sinon, le modèle le plus spécifique est celui qui correspond à un sous-ensemble approprié des packages correspondant au modèle le moins spécifique. Dans notre exemple précédent, chaque package correspondant correspond /npm/space/* également/npm/*, mais l'inverse n'est pas vrai, ce qui rend /npm/space/* le modèle plus spécifique car il s'agit d'un sous-ensemble approprié de/npm/*. Comme un groupe est un sous-ensemble d'un autre groupe, il crée une hiérarchie dans laquelle /npm/space/* se trouve un sous-groupe du groupe parent. /npm/*

Bien que seule la configuration du groupe de packages le plus spécifique s'applique à un package, ce groupe peut être configuré pour hériter de la configuration de son groupe parent.

Mots, limites de mots et correspondance de préfixes

Avant de discuter de la correspondance des préfixes, définissons quelques termes clés :

• Un mot est une lettre ou un chiffre suivi de zéro ou de plusieurs lettres, chiffres ou caractères de marque (tels que des accents, des trémas, etc.).

• La limite d'un mot se trouve à la fin d'un mot, lorsqu'un caractère autre qu'un mot est atteint. Les caractères autres que les mots sont des caractères de ponctuation tels que .-, et. _

Plus précisément, le modèle regex pour un mot est[\p{L}\p{N}][\p{L}\p{N}\p{M}]*, qui peut être décomposé comme suit :

• \p{L}représente n'importe quelle lettre.

• \p{N}représente un nombre quelconque.

• \p{M}représente n'importe quel caractère de marque, tel que les accents, les trémas, etc.

Par conséquent, [\p{L}\p{N}] représente un chiffre ou une lettre, et [\p{L}\p{N}\p{M}]* représente zéro ou plusieurs lettres, chiffres ou caractères de marque et une limite de mot se trouve à la fin de chaque correspondance de ce modèle d'expression régulière.

Note

La correspondance des limites des mots est basée sur cette définition d'un « mot ». Il n'est pas basé sur des mots définis dans un dictionnaire, ou CameCase. Par exemple, il n'y a pas de limite de mots dans oneword ouOneWord.

Maintenant que le mot et la limite des mots sont définis, nous pouvons les utiliser pour décrire la correspondance des préfixes dans CodeArtifact. Pour indiquer une correspondance de préfixe sur la limite d'un mot, un caractère correspondant (~) est utilisé après un caractère de mot. Par exemple, le modèle /npm/space/foo~ correspond aux chemins du package /npm/space/foo et/npm/space/foo-bar, mais pas à /npm/space/food ou/npm/space/foot.

Un caractère générique (*) doit être utilisé plutôt que ~ lorsque vous suivez un caractère autre qu'un mot, comme dans le modèle. /npm/*

Sensibilité à la casse

Les définitions de groupes de packages font la distinction majuscules/majuscules, ce qui signifie que les modèles qui ne diffèrent que par majuscules peuvent exister en tant que groupes de packages distincts. Par exemple, un utilisateur peut créer des groupes de packages distincts avec les modèles /npm//AsyncStorage$/npm//asyncStorage$, et /npm//asyncstorage$ pour les trois packages distincts qui existent dans le registre public npm : AsyncStorage, AsyncStorage, asyncstorage qui ne diffèrent qu'au cas par cas.

Bien que le cas soit important, associez CodeArtifact toujours les packages à un groupe de packages si le package présente une variation du modèle qui diffère au cas par cas. Si un utilisateur crée le groupe de /npm//AsyncStorage$ packages sans créer les deux autres groupes indiqués ci-dessus, toutes les variantes majuscules du nom AsyncStorage, y compris asyncStorage et asyncstorage, seront associées au groupe de packages. Mais, comme décrit dans la section suivanteMatch fort et faible, ces variations seront traitées différemment de AsyncStoragece qui correspond exactement au modèle.

Match fort et faible

Les informations de la section précédente indiquent que Sensibilité à la casse les groupes de packages distinguent les majuscules et minuscules, puis expliquent qu'ils ne le font pas. Cela est CodeArtifact dû au fait que les définitions des groupes de packages reposent sur un concept de correspondance forte (ou correspondance exacte) et de correspondance faible (ou correspondance de variation). Une bonne correspondance se produit lorsque l'emballage correspond exactement au modèle, sans aucune variation. Une faible correspondance se produit lorsque le colis correspond à une variante du modèle, par exemple une majuscule différente. Un comportement de correspondance faible empêche les packages qui sont des variantes du modèle d'un groupe de packages de se transformer en un groupe de packages plus général. Lorsqu'un package est une variante (correspondance faible) du modèle du groupe correspondant le plus spécifique, le package est associé au groupe mais le package est bloqué au lieu d'appliquer la configuration de contrôle d'origine du groupe, empêchant ainsi toute nouvelle version du package d'être extraite des flux ascendants ou publiée. Ce comportement réduit le risque d'attaques de la chaîne d'approvisionnement résultant de la confusion des dépendances entre des packages portant des noms presque identiques.

Pour illustrer le comportement de faible correspondance, supposons que le groupe de packages /npm/* autorise l'ingestion et bloque la publication. Un groupe de packages plus spécifique est configuré pour bloquer l'ingestion et autoriser la publication. /npm//anycompany-spicy-client$ Le package nommé anycompany-spicy-clientcorrespond parfaitement au groupe de packages, ce qui permet de publier des versions de package et bloque l'ingestion de versions de package. La seule case du nom du package qui peut être publiée est anycompany-spicy-clientcelle qui correspond parfaitement au modèle de définition du package. La publication d'une variante différente, telle que AnyCompany-spicy-client, est bloquée en raison d'une faible correspondance. Plus important encore, le groupe de packages bloque l'ingestion de toutes les variantes majuscules, et pas seulement du nom en minuscules utilisé dans le modèle, réduisant ainsi le risque d'attaque par confusion des dépendances.

Variations supplémentaires

Outre les différences entre majuscules et minuscules, la faible correspondance ignore également les différences entre les séquences de tirets-, de points., de traits de soulignement _ et de caractères confuses (tels que les caractères d'apparence similaire issus d'alphabets distincts). Lors de la normalisation utilisée pour les correspondances faibles, CodeArtifact effectue le pliage en majuscules (comme lors de la conversion en minuscules), remplace les séquences de tirets, de points et de soulignements par un seul point et normalise les caractères susceptibles de confusion.

La correspondance faible traite les tirets, les points et les traits de soulignement comme équivalents, mais ne les ignore pas complètement. Cela signifie que foo-bar, foo.bar, foo.. bar et foo_bar sont tous des équivalents à faible correspondance, mais pas foobar. Bien que plusieurs référentiels publics mettent en œuvre des mesures pour empêcher ces types de variations, la protection fournie par les référentiels publics ne rend pas cette fonctionnalité des groupes de packages inutile. Par exemple, les référentiels publics tels que le registre public npm n'empêcheront les nouvelles variantes du package nommé my-package que si my-package y est déjà publié. Si my-package est un package interne et qu'un groupe de packages /npm//my-package$ est créé pour autoriser la publication et bloquer l'ingestion, vous ne voudrez probablement pas publier mon-package dans le registre public npm afin d'empêcher une variante telle que my.package d'être autorisée.

Bien que certains formats de package tels que Maven traitent ces caractères différemment (Maven les traite . comme un séparateur de hiérarchie d'espaces de noms, mais pas - ou_), des éléments tels que com.act-on peuvent toujours être confondus avec com.act.on.

Note

Notez que chaque fois que plusieurs variantes sont associées à un groupe de packages, un administrateur peut créer un nouveau groupe de packages pour une variante spécifique afin de configurer un comportement différent pour cette variante.