Amazon ya no CodeCatalyst está abierto a nuevos clientes. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cómo migrar desde CodeCatalyst](migration.md).
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.
# Publicación y modificación de paquetes
Un *paquete* CodeCatalyst es un paquete de software y los metadatos necesarios para resolver las dependencias e instalar el software. Para obtener una lista de los formatos de paquete compatibles CodeCatalyst, consulte[Publica y comparte paquetes de software en CodeCatalyst](packages.md). Esta sección proporciona información sobre la publicación, la visualización, la eliminación de paquetes y la actualización del estado de una versión del paquete.
**Topics**
+ [Publicar paquetes en un repositorio de CodeCatalyst paquetes](package-publishing.md)
+ [Visualización de detalles de la versión del paquete](working-with-packages-view.md)
+ [Eliminación de una versión del paquete](working-with-packages-delete.md)
+ [Actualización del estado de la versión de un paquete](working-with-packages-update-version-status.md)
+ [Edición de los controles de origen de los paquetes](package-origin-controls.md)
# Publicar paquetes en un repositorio de CodeCatalyst paquetes
Puede publicar versiones de cualquier tipo de paquete compatible en un repositorio de CodeCatalyst paquetes mediante las herramientas del administrador de paquetes. Los pasos para publicar una versión del paquete son los siguientes:
**Para publicar una versión de paquete en un repositorio de CodeCatalyst paquetes**
1. Si no lo ha hecho, [cree un repositorio de paquetes](packages-repositories-create.md).
1. Conecte el administrador de paquetes al repositorio de paquetes. Para obtener instrucciones sobre cómo conectar el administrador de paquetes npm a un repositorio de CodeCatalyst paquetes, consulte[Configuración y uso de npm](packages-npm-use.md).
1. Utilice el administrador de paquetes conectado para publicar las versiones de los paquetes.
**Contents**
+ [Repositorios editoriales y originales](#package-publishing-upstreams)
+ [Paquetes privados y repositorios públicos](#package-publishing-upstreams-direct)
+ [Sobrescribir los activos del paquete](#package-publishing-overwrite-assets)
## Repositorios editoriales y originales
En CodeCatalyst, no puede publicar versiones de paquetes que estén presentes en repositorios ascendentes o repositorios públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete npm (`lodash@1.0`) en un repositorio de paquetes (`myrepo`), y que `myrepo` está conectado a npmjs.com a través de un repositorio de puerta de enlace configurado como repositorio ascendente. Si `lodash@1.0` está presente en el repositorio original o en npmjs.com, CodeCatalyst rechaza cualquier intento de publicación en él emitiendo un error 409 de conflicto. `myrepo` Esto ayuda a evitar la publicación accidental de un paquete con el mismo nombre y la misma versión que un paquete en un repositorio ascendente, lo que puede provocar un comportamiento inesperado.
Puede seguir publicando diferentes versiones del nombre de un paquete que esté en un repositorio ascendente. Por ejemplo, si `lodash@1.0` está en un repositorio ascendente, pero `lodash@1.1` no, puede publicar `lodash@1.1` en el repositorio descendente.
## Paquetes privados y repositorios públicos
CodeCatalyst no publica los paquetes almacenados en CodeCatalyst repositorios públicos, como npmjs.com o Maven Central. CodeCatalyst importa paquetes de repositorios públicos a un CodeCatalyst repositorio, pero no los mueve en la dirección opuesta. Los paquetes que publiques en los CodeCatalyst repositorios permanecen privados y solo están disponibles para el CodeCatalyst proyecto al que pertenece el repositorio.
## Sobrescribir los activos del paquete
No puede volver a publicar un activo de paquete que ya existe con un contenido diferente. Por ejemplo, suponga que ya publicó un paquete de Maven con un activo `mypackage-1.0.jar` JAR. Solo puede volver a publicar ese activo si la suma de comprobación de los activos antiguos y nuevos es idéntica. Para volver a publicar el mismo activo con contenido nuevo, elimine primero la versión del paquete. Si intenta volver a publicar el mismo nombre de activo con un contenido diferente, se producirá un error de conflicto con el protocolo HTTP 409.
Para los formatos de paquetes que admiten varios activos (Python y Maven), puede añadir nuevos activos con nombres diferentes a una versión de paquete existente en cualquier momento, siempre que tenga los permisos necesarios. Dado que npm NuGet solo admite un activo por versión de paquete, para modificar una versión de paquete publicada, primero debes eliminarla.
Si intenta volver a publicar un activo que ya existe (por ejemplo, `mypackage-1.0.jar`) y el contenido del activo publicado y el nuevo son idénticos, la operación se realizará correctamente porque la operación es idempotente.
# Visualización de detalles de la versión del paquete
Puede usar la CodeCatalyst consola para ver los detalles sobre una versión de paquete específica.
**Visualización de detalles de la versión del paquete**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que contenga la versión del paquete cuyos detalles quiera ver.
1. Busque la versión del paquete en la tabla **Paquetes**. Puede utilizar la barra de búsqueda para filtrar paquetes por nombre y formato. Elija el paquete en la lista.
1. En la página **Detalles del paquete**, seleccione **Versiones** y elija la versión que quiera ver.
# Eliminación de una versión del paquete
Puede eliminar una versión del paquete desde la página de **detalles de la versión del paquete** de la CodeCatalyst consola.
**Eliminación de una versión del paquete**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que contenga la versión del paquete que desee eliminar.
1. Busque y seleccione el paquete en la tabla.
1. En la página **Detalles del paquete**, seleccione **Versiones** y elija la versión que quiera eliminar.
1. En la página **Detalles de la versión del paquete**, seleccione **Acciones de versión** y después seleccione **Eliminar**.
1. Escriba *delete* en el cuadro de texto y elija **Eliminar**.
# Actualización del estado de la versión de un paquete
Cada versión del paquete CodeCatalyst tiene un estado que describe el estado actual y la disponibilidad de la versión del paquete. Puede cambiar el estado de la versión del paquete en la CodeCatalyst consola. Para obtener más información sobre los posibles valores de estado de las versiones de los paquetes y sus significados, consulte [Estado de la versión del paquete](#package-version-status).
**Actualización del estado de la versión de un paquete**
1. En el panel de navegación, elija **Paquetes**.
1. En la página **Repositorios de paquetes**, elija el repositorio que contenga la versión del paquete cuyo estado quiera actualizar.
1. Busque y seleccione el paquete en la tabla.
1. En la página **Detalles del paquete**, seleccione **Versiones** y elija la versión que quiera ver.
1. En la página **Detalles de la versión del paquete**, elija **Acciones** y seleccione **Quitar de la lista**, **Archivar** o **Desechar**. Para obtener información sobre el estado de cada versión del paquete, consulte [Estado de la versión del paquete](#package-version-status).
1. Introduzca el texto de confirmación en el campo de texto y seleccione **Quitar de la lista**, **Archivar** o **Desechar**, según el estado de destino de la actualización.
## Estado de la versión del paquete
Los siguientes son valores posibles para el estado de la versión del paquete. Puede cambiar el estado de la versión del paquete en la consola. Para obtener más información, consulte [Actualización del estado de la versión de un paquete](#working-with-packages-update-version-status).
+ **Publicada**: la versión del paquete se publicó correctamente y se puede solicitar mediante un administrador de paquetes. La versión del paquete se incluirá en las listas de versiones de los paquetes devueltas a los administradores de paquetes, por ejemplo, en la salida de `npm view versions`. Todos los activos de la versión del paquete están disponibles en el repositorio.
+ **Sin terminar**: el último intento de publicación no se completó. Actualmente, solo las versiones de paquetes de Maven pueden tener un estado **Sin terminar**. Esto puede ocurrir cuando el cliente carga uno o más activos para una versión del paquete, pero no publica un archivo `maven-metadata.xml` para el paquete que incluye esa versión.
+ **Sin enumerar**: los activos de la versión del paquete están disponibles para su descarga desde el repositorio, pero la versión del paquete no se incluye en la lista de versiones devueltas a los administradores de paquetes. Por ejemplo, en el caso de un paquete npm, la salida de `npm view versions` no incluye la versión del paquete. Esto significa que la lógica de resolución de dependencias de npm no selecciona la versión del paquete porque la versión no aparece en la lista de versiones disponibles. Sin embargo, si ya se hace referencia a la versión del paquete **Sin enumerar** en un archivo `npm package-lock.json`, aún se puede descargar e instalar, por ejemplo, cuando se ejecuta `npm ci`.
+ **Archivado**: los activos de la versión del paquete no se pueden descargar. La versión del paquete no se incluirá en la lista de versiones devueltas a los administradores de paquetes. Como los activos no están disponibles, los clientes bloquean el consumo de la versión del paquete. Si la compilación de la aplicación depende de una versión actualizada a **Archivado**, la compilación fallará, a no ser que la versión del paquete se haya almacenado en la caché local. No puede usar un administrador de paquetes o una herramienta de compilación para volver a publicar una versión de un paquete **Archivado** porque todavía está presente en el repositorio. Sin embargo, puede cambiar el estado de la versión del paquete a **Sin enumerar** o **Publicada** en la consola.
+ **Eliminar**: la versión del paquete no aparece en las listas y los activos no se pueden descargar del repositorio. La diferencia clave entre **Dispuesto** y **Archivado** es que, con el estado **Dispuesto**, los activos de la versión del paquete se eliminan permanentemente. CodeCatalyst Por este motivo, no puede mover una versión de paquete de **Eliminar** a **Archivado**, **Sin enumerar** o **Publicada**. La versión del paquete no se puede utilizar porque se han eliminado los activos. Si una versión del paquete se ha marcado como **Eliminar**, ya no se le facturará el almacenamiento de los activos del paquete.
Además de los estados de la lista anterior, la versión de un paquete también se puede eliminar. Una vez eliminada, la versión de un paquete deja de estar en el repositorio y puede volver a publicarla libremente mediante un administrador de paquetes o una herramienta de compilación.
## Normalización del nombre del paquete, la versión del paquete y el nombre del activo
CodeCatalyst normaliza los nombres de los paquetes, las versiones de los paquetes y los nombres de los activos antes de almacenarlos, lo que significa que los nombres o las versiones CodeCatalyst pueden ser diferentes del nombre o la versión proporcionados cuando se publicó el paquete. Para obtener más información sobre cómo se normalizan los nombres y las versiones CodeCatalyst para cada tipo de paquete, consulte la siguiente documentación.
+ [Normalización de nombres de paquetes de Python](python-name-normalization.md)
+ [NuGet normalización del nombre del paquete, la versión y el nombre del activo](nuget-name-normalization.md)
CodeCatalyst no realiza la normalización en otros formatos de paquete.
# Edición de los controles de origen de los paquetes
En Amazon CodeCatalyst, las versiones de los paquetes se pueden añadir a un repositorio de paquetes publicándolas directamente, retirándolas de un repositorio anterior o incorporándolas desde un repositorio público externo a través de una puerta de enlace. Si permite que las versiones de un paquete se añadan mediante publicación directa e ingestión desde repositorios públicos, quedará en un estado de vulnerabilidad ante un ataque de sustitución de dependencias. Para obtener más información, consulte [Ataques de sustitución de dependencias](#dependency-substitution-attacks). Para protegerse de un ataque de sustitución de dependencias, configure los controles de origen de los paquetes de un repositorio para limitar la forma en que se pueden añadir las versiones de ese paquete al repositorio.
Debería valorar la posibilidad de configurar controles de orígenes de paquetes para que las nuevas versiones de diferentes paquetes vengan tanto de orígenes internos, como la publicación directa, como de externos, como los repositorios públicos. De forma predeterminada, los controles de origen de los paquetes se configurarán en función de cómo se añada la primera versión del paquete al repositorio.
## Configuración de los controles de origen del paquete
Con los controles de origen de los paquetes, puede configurar cómo se pueden añadir las versiones de los paquetes a un repositorio. Las siguientes listas incluyen la configuración y los valores de control de origen de los paquetes disponibles.
**Publish**
Esta configuración configura si las versiones de los paquetes se pueden publicar directamente en el repositorio mediante administradores de paquetes o herramientas similares.
+ **ALLOW**: las versiones de los paquetes se pueden publicar directamente.
+ **BLOCK**: las versiones de los paquetes no se pueden publicar directamente.
**Repositorios ascendentes**
Esta configuración configura si las versiones de los paquetes pueden ingerirse desde repositorios públicos externos o conservarse desde repositorios originales cuando lo solicite un administrador de paquetes.
+ **PERMITIR**: Se puede conservar cualquier versión de paquete de otros CodeCatalyst repositorios configurados como repositorios anteriores o bien se puede ingerir desde una fuente pública con una conexión externa.
+ **BLOCK**: Las versiones de los paquetes no se pueden conservar de otros CodeCatalyst repositorios configurados como repositorios ascendentes ni se pueden ingerir desde una fuente pública con una conexión externa.
### Configuración predeterminada de los controles de origen de los paquetes
Los controles de origen de los paquetes predeterminados se basarán en la forma en que se añada la primera versión de ese paquete al repositorio de paquetes.
+ Si un administrador de paquetes publica directamente la primera versión del paquete, la configuración será **Publish: ALLOW** y **Upstream: BLOCK**.
+ Si la primera versión del paquete proviene de una fuente pública, los ajustes serán **Publish: BLOCK** y **Upstream: BLOCK**.
## Escenarios comunes de control de acceso a paquetes
En esta sección se describen algunos escenarios comunes en los que se agrega una versión de paquete a un repositorio de paquetes. CodeCatalyst Los ajustes de control de origen del paquete se establecerán para los paquetes nuevos en función de cómo se añada la primera versión del paquete.
En los siguientes escenarios, un *paquete interno* se publica directamente desde un administrador de paquetes en el repositorio, como un paquete que usted mantenga. Un *paquete externo* es un paquete que existe en un repositorio público y que puede incorporarse al repositorio mediante una conexión ascendente a un repositorio de puerta de enlace.
**Se publica una versión de paquete externo para un paquete interno existente**
En este escenario, consideremos un paquete interno, *packageA*. Su equipo publica la primera versión del paquete del paquete A *en* un repositorio de CodeCatalyst paquetes. Como esta es la primera versión del paquete, la configuración del control de origen del paquete se establece automáticamente en **Publish: Allow** and **Upstream: Block**. Una vez publicado el paquete en tu repositorio, se publica un paquete con el mismo nombre en un repositorio público que está conectado a tu repositorio de CodeCatalyst paquetes. Podría tratarse de un intento de ataque de sustitución de dependencias contra el paquete interno o podría ser una coincidencia. En cualquier caso, los controles de origen de los paquetes están configurados para bloquear la ingesta de la nueva versión externa y protegerse así de un posible ataque.
En la siguiente imagen, *RePoA* es tu repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. `npm-public-registry-gateway` Su repositorio contiene las versiones 1.1 y 2.1 de *packageA*, pero la versión 3.0 está publicada en el repositorio público. Normalmente, *repoA* ingiere la versión 3.0 después de que un administrador de paquetes solicite el paquete. Como la ingesta de paquetes está configurada como **Bloquear**, la versión 3.0 no se ingiere en su repositorio de CodeCatalyst paquetes y no está disponible para los administradores de paquetes conectados a él.
![\[Gráfico sencillo que muestra el bloqueo de una nueva versión de un paquete externo en un repositorio público.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png)
**Se publica una versión de paquete interno para un paquete externo existente**
En este escenario, un paquete, *packageB*, existe externamente en un repositorio público que usted ha conectado a su repositorio. Cuando un administrador de paquetes conectado a su repositorio solicita el *packageB*, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete de *packageB* que se agrega a su repositorio, los ajustes de origen del paquete están configurados como **Publish: BLOCK** y **Upstream: ALLOW**. Más adelante, intenta publicar una versión con el mismo nombre de paquete en el repositorio. Es posible que no conozca el paquete público y esté intentando publicar un paquete no relacionado con el mismo nombre, que esté intentando publicar una versión parcheada o que esté intentando publicar directamente la versión exacta del paquete que ya existe de forma externa. CodeCatalyst rechaza la versión que está intentando publicar, pero puede anular el rechazo de forma explícita y publicar la versión, si es necesario.
En la imagen siguiente, *RePoA* es el repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. `npm-public-registry-gateway` Su repositorio de paquetes contiene la versión 3.0 que ingirió del repositorio público. Quiere publicar la versión 1.2 en el repositorio de paquetes. Normalmente, podría publicar la versión 1.2 en *repoA*, pero como la publicación está configurada en **Block**, la versión 1.2 no se puede publicar.
![\[Gráfico simple que muestra la publicación de paquetes bloqueada.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png)
**Publicar una versión parcheada de un paquete externo existente**
En este escenario, un paquete, *packageB*, existe externamente en un repositorio público que usted ha conectado al repositorio de paquetes. Cuando un administrador de paquetes conectado a su repositorio solicita el *packageB*, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete de *packageB* que se agrega a su repositorio, los ajustes de origen del paquete están configurados como **Publish: BLOCK** y **Upstream: ALLOW**. Su equipo decide publicar las versiones de los paquetes parcheados de este paquete en el repositorio. Para poder publicar las versiones de los paquetes directamente, su equipo cambia la configuración del control de origen de los paquetes a **Publish: ALLOW** y **Upstream: BLOCK**. Las versiones de este paquete ahora se pueden publicar directamente en su repositorio e ingerir desde los repositorios públicos. Una vez que su equipo publique las versiones de los paquetes parcheados, cambiará la configuración de origen del paquete a **Publish: BLOCK** and **Upstream: ALLOW**.
## Edición de los controles de origen de los paquetes
Los controles de origen de los paquetes se configuran automáticamente en función de cómo se añade la primera versión del paquete al repositorio de paquetes. Para obtener más información, consulte [Configuración predeterminada de los controles de origen de los paquetes](#default-package-origin-control-settings). Para añadir o editar los controles de origen de un paquete en un repositorio de CodeCatalyst paquetes, lleve a cabo los pasos del siguiente procedimiento.
**Adición o edición de los controles de origen del paquete**
1. En el panel de navegación, elija **Paquetes**.
1. Elija el repositorio de paquetes que contenga el paquete que desea editar.
1. En la tabla **Paquetes**, busque y seleccione el paquete que desee editar.
1. En la página de resumen del paquete, seleccione **Controles de origen**.
1. En **Controles de origen**, seleccione los controles de origen del paquete que desee configurar para este paquete. Los dos ajustes de control de origen del paquete (**Publicar** y **Ascendente**) deben configurarse al mismo tiempo.
+ Para permitir la publicación directa de las versiones de los paquetes, en **Publicar**, seleccione **Permitir**. Para bloquear la publicación de versiones de paquetes, seleccione **Bloquear**.
+ Para permitir la ingesta de paquetes de repositorios externos y la extracción de paquetes de repositorios anteriores, en **Recursos ascendentes**, seleccione **Permitir**. Para bloquear la ingesta y la extracción de versiones de paquetes desde repositorios externos y ascendentes, seleccione **Bloquear.**
1. Seleccione **Save**.
## Repositorios editoriales y originales
En CodeCatalyst, no puede publicar versiones de paquetes que estén presentes en repositorios ascendentes o públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete npm `lodash@1.0` en un repositorio (`myrepo`), y que `myrepo` tiene un repositorio ascendente con una conexión externa a npmjs.com. Considere los siguientes escenarios.
1. Los ajustes de control de origen de los paquetes de `lodash` son **Publish: ALLOW y **Upstream: ALLOW****. Si `lodash@1.0` está presente en el repositorio original o en npmjs.com, CodeCatalyst rechaza cualquier intento de publicación en él emitiendo un error 409 de conflicto. `myrepo` Aún puede publicar una versión diferente, por ejemplo `lodash@1.1`.
1. Los ajustes de control de origen de los paquetes de `lodash` son **Publish: ALLOW y **Upstream: BLOCK****. Puede publicar en su repositorio cualquier versión de `lodash` que aún no exista, porque no se puede acceder a las versiones de los paquetes.
1. Los ajustes de control de origen de los paquetes de `lodash` son **Publish: BLOCK** y **Upstream: ALLOW**. No puede publicar ninguna versión del paquete directamente en su repositorio.
## Ataques de sustitución de dependencias
Los administradores de paquetes simplifican el proceso de empaquetar y compartir código reutilizable. Estos paquetes pueden ser paquetes privados desarrollados por una organización para usarlos en sus aplicaciones, o pueden ser públicos, generalmente paquetes de código abierto que se desarrollan fuera de una organización y se distribuyen en repositorios de paquetes públicos. Al solicitar paquetes, los desarrolladores confían en su administrador de paquetes para obtener nuevas versiones de sus dependencias. Los ataques de sustitución de dependencias, también conocidos como ataques de confusión de dependencias, aprovechan el hecho de que un administrador de paquetes normalmente no tiene forma de distinguir las versiones legítimas de un paquete de las versiones maliciosas.
Los ataques de sustitución de dependencias pertenecen a un subconjunto de ataques conocidos como ataques a la cadena de suministro de software. Un ataque a la cadena de suministro de software es un ataque que aprovecha las vulnerabilidades en cualquier punto de la cadena de suministro de software.
Un ataque de sustitución de dependencias puede dirigirse a cualquier persona que utilice tanto paquetes desarrollados internamente como paquetes extraídos de repositorios públicos. Los atacantes identifican los nombres de los paquetes internos y, a continuación, colocan estratégicamente el código malicioso con el mismo nombre en los repositorios de paquetes públicos. Normalmente, el código malicioso se publica en un paquete con un número de versión alto. Los administradores de paquetes obtienen el código malicioso de estas fuentes públicas porque creen que los paquetes maliciosos son las últimas versiones del paquete. Esto provoca una confusión o una sustitución entre el paquete deseado y el paquete malicioso, lo que hace que el código quede comprometido.
Para evitar los ataques de sustitución de dependencias, Amazon CodeCatalyst proporciona controles de origen de los paquetes. Los controles de origen de los paquetes son ajustes que controlan cómo se pueden añadir los paquetes a los repositorios. Los controles se configuran automáticamente cuando se añade la primera versión de un paquete nuevo a un CodeCatalyst repositorio. Los controles pueden garantizar que las versiones de los paquetes no puedan publicarse directamente en su repositorio ni ingerirse desde fuentes públicas, lo que le protege de los ataques de sustitución de dependencias. Para obtener más información sobre los controles de origen de los paquetes y cómo cambiarlos, consulte [Edición de los controles de origen de los paquetes](#package-origin-controls).