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 space es /npm/space/anycompany-ui-components.

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 nombres de los paquetes de NuGet, Python y Swift, así como los espacios de nombres de los paquetes de Swift antes de almacenarlos. CodeArtifact usa estos nombres normalizados al hacer coincidir paquetes con definiciones de 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 y los espacios de nombres de los paquetes, consulte la documentación de normalización de nombres de NuGet, Python y Swift.

Espacios de nombres en las definiciones de grupos de paquetes

Para los paquetes o formatos de paquetes sin espacios 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 «dentro de» o «asociados a» un grupo de paquetes son paquetes con una ruta que coincide con el patrón del grupo, pero no con el patrón de un grupo más específico. Por ejemplo, dados 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 asociadas 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ífica 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 ya sabemos lo que son las palabras y los límites de palabras, podemos usarlos para describir las coincidencias de prefijos en 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/*.

Sensibilidad de 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 independientes con los patrones /npm//AsyncStorage$, /npm//asyncStorage$ y /npm//asyncstorage$ para los tres paquetes independientes que existen en el registro público de npm: AsyncStorage, asyncStorage y asyncstorage, que solo difieren respecto de las mayúsculas y las minúsculas.

Si bien las mayúsculas y las minúsculas importan, CodeArtifact sigue asociando paquetes a un grupo de paquetes si el paquete solo varía en las mayúsculas y minúsculas del patrón. Si un usuario crea el grupo de paquetes /npm//AsyncStorage$ sin crear los otros dos grupos que se muestran arriba, todas las variantes respecto de las mayúsculas y las minúsculas del nombre AsyncStorage, incluidas asyncStorage y asyncstorage, se asociarán al grupo de paquetes. Sin embargo, como se describe en la siguiente sección, Coincidencias férreas e inconsistentes, estas variantes se gestionarán de forma diferente a AsyncStorage, que es una coincidencia exacta del patrón.

Coincidencias férreas e inconsistentes

En la sección anterior, Sensibilidad de 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 de CodeArtifact contemplan los conceptos de «coincidencia férrea» (exacta) y «coincidencia inconsistente» (variante). 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 inconsistente impide que los paquetes que son variantes 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 inconsistente) 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 los controles de origen del grupo, lo que impide que cualquier versión nueva del paquete se extraiga de secuencias ascendentes 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. Cualquier variante en cuanto a las mayúsculas y las minúsculas, como AnyCompany-spicy-client, no puede publicarse porque constituye una coincidencia inconsistente. 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 utilizada para las coincidencias inconsistentes, CodeArtifact convierte los nombres a formas canónicas independientes de mayúsculas y minúsculas (parecido a pasarlos a minúsculas), reemplaza las secuencias de guiones, puntos y guiones bajos por un solo punto y normaliza 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 son varios los repositorios públicos que implementan medidas para evitar este tipo de variantes, la protección que proporcionan este tipo de repositorios no hace innecesaria esta características de los grupos de paquetes. Por ejemplo, los repositorios públicos, como el registro público de npm, solo evitarán nuevas variantes 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.