Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Sintaxis de la definición de los grupos de paquetes y comportamiento coincidente

Este tema contiene información sobre la definición de los grupos de paquetes, el comportamiento coincidente de patrones, la solidez de la asociación de paquetes y la jerarquía de los grupos de paquetes.

Sintaxis de la definición de los grupos de paquetes y ejemplos

La sintaxis de los patrones para definir los grupos de paquetes es muy similar al formato de las rutas de los paquetes. La ruta de un paquete se crea a partir de los componentes de coordenadas del paquete (formato, espacio de nombres y nombre) añadiendo una barra inclinada al principio y separando cada uno de los componentes con otras. Por ejemplo, la ruta del paquete npm denominado anycompany-ui-components en el espacio de nombres es /anycompany-ui-components. npm/space

El patrón de un grupo de paquetes sigue la misma estructura que la ruta de un paquete, salvo porque se omiten los componentes que no se especifican como parte de la definición del grupo y el patrón termina con un sufijo. El sufijo que se incluye determina el comportamiento coincidente del patrón de la siguiente manera:

A continuación, encontrará ejemplos de patrones para cada una de las combinaciones permitidas:

Como se muestra en los ejemplos anteriores, el sufijo ~ se añade al final de un espacio de nombres o un nombre para representar una coincidencia de prefijos y * se añade tras una barra inclinada para hacer coincidir todos los valores del siguiente componente de la ruta (todos los formatos, todos los espacios de nombres o todos los nombres).

Definición y normalización de grupos de paquetes

CodeArtifact normaliza los NuGet nombres de los paquetes de Python y Swift, y normaliza los espacios de nombres de los paquetes de Swift antes de almacenarlos. CodeArtifact usa estos nombres normalizados al hacer coincidir los paquetes con las definiciones de los grupos de paquetes. Por lo tanto, los grupos de paquetes que contienen un espacio de nombres o un nombre con estos formatos deben usar el espacio de nombres y el nombre normalizados. Para obtener más información sobre cómo se normalizan los nombres de los paquetes y los espacios de nombres, consulte la documentación de normalización de nombres de NuGetPython y Swift.

Espacios de nombres en las definiciones de grupos de paquetes

Para los paquetes o formatos de paquetes sin un espacio de nombres (Python y NuGet), los grupos de paquetes no deben contener un espacio de nombres. La definición del grupo de paquetes de estos grupos de paquetes contiene una sección de espacio de nombres en blanco. Por ejemplo, la ruta del paquete de Python denominado requests es /python//requests.

Para los paquetes o los formatos de paquetes con un espacio de nombres (Maven, genérico y Swift), el espacio de nombres debe incluirse si se incluye el nombre del paquete. Para el formato de paquete Swift, se utilizará el espacio de nombres del paquete normalizado. Para obtener más información sobre cómo se normalizan los espacios de nombres de los paquetes de Swift, consulte Normalización del nombre del paquete y del espacio de nombres de Swift.

Jerarquía de los grupos de paquetes y especificidad de los patrones

Los paquetes que están «en» o «asociados» a un grupo de paquetes son paquetes con una ruta de paquete que coincide con el patrón del grupo, pero no con el patrón de un grupo más específico. Por ejemplo, teniendo en cuenta los grupos de paquetes /npm/* y/npm/space/*, la ruta del paquete /npm//react está asociada al primer grupo (/npm/*), mientras que npm/space//aui.components y/npm/space/amplify-ui-core están asociados al segundo grupo (). /npm/space/* Aunque un paquete puede coincidir con varios grupos, cada paquete solo está asociado a un grupo, la coincidencia más específica, y solo la configuración de ese grupo se aplica al paquete.

Cuando la ruta de un paquete coincide con varios patrones, el patrón «más específico» puede considerarse el patrón coincidente más largo. Como alternativa, el patrón más específico es el que coincide con un subconjunto adecuado de los paquetes que coinciden con el patrón menos específico. En el ejemplo anterior, todos los paquetes que coinciden con /npm/space/* también coinciden con /npm/*, pero no ocurre lo contrario, lo que hace que /npm/space/* sea el patrón más específico, ya que es un subconjunto adecuado de /npm/*. Como un grupo es un subconjunto de otro grupo, crea una jerarquía, en la que /npm/space/* es un subgrupo del grupo principal, /npm/*.

Aunque solo la configuración del grupo de paquetes más específico se aplica a un paquete, ese grupo puede configurarse para heredar la configuración de su grupo principal.

Coincidencia de palabras, de límites de palabra y de prefijos

Antes de hablar sobre la coincidencia de prefijos, tenemos que definir algunos términos clave:

En concreto, el patrón de expresiones regulares de una palabra es [\p{L}\p{N}][\p{L}\p{N}\p{M}]*, que se puede desglosar de la siguiente manera:

Por lo tanto, [\p{L}\p{N}] representa un número o una letra y [\p{L}\p{N}\p{M}]* representa cero o más letras, números o marcas diacríticas, y el límite de una palabra se encuentra al final de cada coincidencia de este patrón de expresiones regulares.

Ahora que la palabra y el límite de la palabra están definidos, podemos usarlos para describir la coincidencia de prefijos. CodeArtifact Para indicar una coincidencia de prefijo en un límite de palabra, se utiliza un carácter coincidente (~) tras un carácter de palabra. Por ejemplo, el patrón /npm/space/foo~ coincide con las rutas de los paquetes /npm/space/foo y/npm/space/foo-bar, pero no con /npm/space/food ni /npm/space/foot.

Es necesario utilizar un comodín (*) en vez de ~ tras un carácter distinto a una palabra, como en el patrón /npm/*.

Sensible a mayúsculas y minúsculas

Las definiciones de los grupos de paquetes distinguen entre mayúsculas y minúsculas, lo que significa que los patrones que solo difieren en cuanto a las mayúsculas y las minúsculas pueden existir como grupos de paquetes independientes. Por ejemplo, un usuario puede crear grupos de paquetes separados con los patrones /npm//AsyncStorage$ y /npm//asyncstorage$ para los tres paquetes separados que existen en el registro público de npm: asyncStorage y asyncstorage AsyncStorage, que solo difieren según las mayúsculas y minúsculas. /npm//asyncStorage$

Si bien las mayúsculas y minúsculas importan, CodeArtifact sigue asociando los paquetes a un grupo de paquetes si el paquete tiene una variación del patrón que difiere según las mayúsculas y minúsculas. Si un usuario crea el grupo de /npm//AsyncStorage$ paquetes sin crear los otros dos grupos que se muestran arriba, todas las variantes del nombre en mayúsculas y minúsculas AsyncStorage, incluidas AsyncStorage y asyncstorage, se asociarán al grupo de paquetes. Sin embargo, como se describe en la siguiente secciónCoincidencias férreas e inconsistentes, estas variaciones se tratarán de forma diferente AsyncStoragea la que se corresponde exactamente con el patrón.

Coincidencias férreas e inconsistentes

En la sección anterior, Sensible a mayúsculas y minúsculas, se indica que los grupos de paquetes distinguen mayúsculas de minúsculas y, a continuación, se explica que no distinguen mayúsculas de minúsculas. Esto se debe a que las definiciones de los grupos de paquetes CodeArtifact tienen un concepto de coincidencia fuerte (o coincidencia exacta) y de coincidencia débil (o coincidencia de variantes). Una coincidencia férrea es cuando el paquete coincide exactamente con el patrón, sin variantes. Una coincidencia inconsistente se produce cuando el paquete coincide con una variante del patrón; por ejemplo, con diferencias en cuanto al uso de mayúsculas y minúsculas. El comportamiento de coincidencia débil impide que los paquetes que son variaciones del patrón de un grupo de paquetes se acumulen en un grupo de paquetes más general. Cuando un paquete es una variante (coincidencia débil) del patrón del grupo coincidente más específico, el paquete se asocia al grupo, pero el paquete se bloquea en lugar de aplicar la configuración de control de origen del grupo, lo que impide que cualquier nueva versión del paquete se extraiga de las versiones anteriores o se publique. Este comportamiento reduce el riesgo de que se produzcan ataques a la cadena de suministro por confusión de dependencias entre paquetes con nombres casi idénticos.

Para ilustrar el comportamiento de coincidencia inconsistente, supongamos que el grupo de paquetes /npm/* permite la ingesta y bloquea la publicación. Un grupo de paquetes más específico, /npm//anycompany-spicy-client$, está configurado para bloquear la ingesta y permitir la publicación. El paquete denominado anycompany-spicy-client representa una coincidencia férrea del grupo de paquetes, lo que permite publicar versiones de los paquetes y bloquea su ingesta. Solo puede publicarse el nombre del paquete con el formato de mayúsculas y minúsculas anycompany-spicy-client, pues supone una coincidencia férrea del patrón de definiciones del paquete. Se bloquea la publicación de una variante de mayúsculas y AnyCompany-spicy-clientminúsculas diferente, como, por ejemplo, porque no coincide suficientemente. Y lo que es más importante: el grupo de paquetes bloquea la ingesta de todas las variantes de mayúsculas y minúsculas, no solo del nombre en minúscula utilizado en el patrón, lo que reduce el riesgo de que se produzca un ataque de confusión de dependencias.

Otras variantes

Además de las diferencias entre mayúsculas y minúsculas, las coincidencias inconsistentes también ignoran las diferencias en las secuencias de guiones (-), puntos (.), guiones bajos (_) y caracteres que pueden confundirse (como aquellos caracteres que se parecen en forma pero pertenecen a alfabetos diferentes). Durante la normalización, que se utiliza para casos de coincidencia débil CodeArtifact , se utilizan mayúsculas y minúsculas (similar a la conversión a minúsculas), se sustituyen las secuencias de guiones, puntos y guiones bajos por un solo punto y se normalizan los caracteres que pueden confundirse.

Las coincidencias inconsistentes consideran que los guiones, puntos y guiones bajos son equivalentes, pero no los ignoran por completo. Esto significa que foo-bar, foo.bar, foo..bar y foo_bar son coincidencias inconsistentes equivalentes, pero que foobar no lo es. Si bien varios repositorios públicos implementan medidas para evitar este tipo de variaciones, la protección que proporcionan los repositorios públicos no hace que esta característica de los grupos de paquetes sea innecesaria. Por ejemplo, los repositorios públicos, como el registro público de npm, solo evitarán nuevas variaciones del paquete denominado my-package si my-package ya está publicado en ellos. Si my-package es un paquete interno y se crea un grupo de paquetes /npm//my-package$ que permite la publicación y bloquea la ingesta, muy probablemente no va a querer publicar my-package en el registro público de npm, porque es la manera de evitar permitir variantes tipo my.package.

Si bien algunos formatos de paquete, como Maven, tratan estos caracteres de manera diferente (Maven considera . un separador jerárquico de los espacios de nombres, pero no lo hace con - ni _), algo como com.act-on todavía podría confundirse con com.act.on.