\n
... more content ... \n",
"versionRevision": "REVISION-SAMPLE-55C752BEE9B772FC"
}
```
# Actualización del estado de la versión del paquete
Cada versión del paquete CodeArtifact 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 mediante la consola AWS CLI y la consola.
**nota**
Para obtener más información sobre el estado de la versión del paquete, incluida una lista de los estados disponibles, consulte [El estado de la versión del paquete](packages-overview.md#package-version-status).
## Actualizar el estado de la versión del paquete
Establecer el estado de la versión de un paquete permite controlar cómo se puede usar una versión del paquete sin eliminarla por completo del repositorio. Por ejemplo, cuando la versión de un paquete tiene el estado de `Unlisted`, se puede seguir descargando de forma normal, pero no aparecerá en las listas de versiones de paquetes devueltas a comandos como `npm view`. La [UpdatePackageVersionsStatus API](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_UpdatePackageVersionsStatus.html) permite configurar el estado de la versión del paquete de varias versiones del mismo paquete en una sola llamada a la API. Para obtener una descripción de los diferentes estados, consulte [Información general sobre paquetes](packages-overview.md).
Utilice el comando `update-package-versions-status` para cambiar el estado de una versión de paquete a `Published`, `Unlisted`, o `Archived`. Para ver los permisos de IAM necesarios para usar el comando, consulte [Permisos de IAM necesarios para actualizar el estado de una versión de paquete](#update-package-version-status-iam). El siguiente ejemplo establece el estado de la versión 4.1.0 del paquete npm `chalk` en `Archived`.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 --target-status Archived
```
Código de salida de ejemplo:
```
{
"successfulVersions": {
"4.1.0": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
En este ejemplo se utiliza un paquete npm, pero el comando funciona de forma idéntica en otros formatos. Se pueden mover varias versiones al mismo estado de destino con un solo comando; consulte el siguiente ejemplo.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 4.1.1 --target-status Archived
```
Código de salida de ejemplo:
```
{
"successfulVersions": {
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Archived"
},
"4.1.1": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
Tenga en cuenta que, una vez publicada, la versión de un paquete no se puede volver a mover al estado `Unfinished`, por lo que este estado no está permitido como valor para el parámetro `--target-status`. Para mover la versión del paquete al estado `Disposed`, utilice el comando `dispose-package-versions` en su lugar, tal como se describe a continuación.
## Permisos de IAM necesarios para actualizar el estado de una versión de paquete
Para llamar a `update-package-versions-status` para un paquete, debe tener el permiso `codeartifact:UpdatePackageVersionsStatus` en el recurso del paquete. Esto significa que puede otorgar permiso para llamar a `update-package-versions-status` por paquete. Por ejemplo, una política de IAM que conceda permiso para invocar `update-package-versions-status` el paquete npm *chalk* incluiría una declaración como la siguiente.
```
{
"Action": [
"codeartifact:UpdatePackageVersionsStatus"
],
"Effect": "Allow",
"Resource": "arn:aws:codeartifact:us-east-1:111122223333:package/my_domain/my_repo/npm//chalk"
}
```
## Se está actualizando el estado de un paquete npm específico
Para actualizar el estado de la versión del paquete de una versión del paquete npm con un alcance, utilice el parámetro `--namespace`. Por ejemplo, para eliminar la versión 8.0.0 de `@nestjs/core`, utilice el siguiente comando.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --namespace nestjs
--package core --versions 8.0.0 --target-status Unlisted
```
## Estado de actualización de un paquete de Maven
Los paquetes de Maven siempre tienen un ID de grupo, que se denomina espacio de nombres en. CodeArtifact Utilice el parámetro `--namespace` para especificar el ID de grupo de Maven al llamar a `update-package-versions-status`. Por ejemplo, para archivar la versión 2.13.1 del paquete Maven `org.apache.logging.log4j:log4j`, utilice el siguiente comando.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format maven
--namespace org.apache.logging.log4j --package log4j
--versions 2.13.1 --target-status Archived
```
## Especificación de una versión de paquete
La revisión de la versión de un paquete es una cadena que especifica un conjunto específico de activos y metadatos para una versión de paquete. Puede especificar una revisión de la versión del paquete para actualizar el estado de las versiones del paquete que se encuentran en un estado específico. Para especificar una revisión de la versión del paquete, utilice el parámetro `--version-revisions` para pasar una o más versiones del paquete separadas por comas y los pares de revisiones de versiones del paquete. El estado de la versión de un paquete solo se actualizará si la revisión actual de la versión del paquete coincide con el valor especificado.
**nota**
El parámetro `—-versions` también debe definirse cuando se utilice el parámetro `--version-revisions`.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8bzVMJ4="
--versions 4.1.0 --target-status Archived
```
Para actualizar varias versiones con un solo comando, pase a las opciones una lista separada por comas de pares de versiones y revisiones a las opciones `--version-revisions`. El siguiente comando de ejemplo define dos pares diferentes de versiones de paquetes y revisiones de versiones de paquetes.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm
--package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=,4.0.0=E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc="
--versions 4.1.0 4.0.0 --target-status Published
```
Código de salida de ejemplo:
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Published"
},
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Published"
}
},
"failedVersions": {}
}
```
Al actualizar varias versiones de paquetes, las versiones que se han pasado a `--version-revisions` deben ser las mismas que las versiones pasadas a `--versions`. Si se especifica una revisión de forma incorrecta, el estado de esa versión no se actualizará.
## Uso del parámetro de estado esperado
El comando `update-package-versions-status` proporciona el parámetro `--expected-status` que permite especificar el estado actual esperado de una versión del paquete. Si el estado actual no coincide con el valor al que se ha pasado a `--expected-status`, el estado de esa versión del paquete no se actualizará.
Por ejemplo, en*my\$1repo*, las versiones 4.0.0 y 4.1.0 del paquete `chalk` npm tienen actualmente un estado de. `Published` Una llamada a `update-package-versions-status` que especifique el estado esperado de no `Unlisted` podrá actualizar ambas versiones del paquete debido a la discordancia de estados.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 4.0.0 --target-status Archived --expected-status Unlisted
```
Código de salida de ejemplo:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
},
"4.1.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
## Errores con las versiones individuales de los paquetes
Existen varios motivos por los que el estado de la versión de un paquete no se actualiza cuando se llama a `update-package-versions-status`. Por ejemplo, es posible que la revisión de la versión del paquete se haya especificado incorrectamente o que el estado esperado no coincida con el estado actual. En estos casos, la versión se incluirá en el mapa `failedVersions` de la respuesta de la API. Si una versión falla, es posible que se omitan las demás versiones especificadas en la misma llamada a `update-package-versions-status` y que su estado no se actualice. Estas versiones también se incluirán en el mapa `failedVersions` con un `errorCode` de `SKIPPED`.
En la implementación actual de `update-package-versions-status`, si no se puede cambiar el estado de una o más versiones, se omitirán todas las demás versiones. Es decir, todas las versiones se actualizan correctamente o no se actualiza ninguna versión. Este comportamiento no está garantizado en el contrato de la API; en el futuro, algunas versiones podrían funcionar correctamente y otras no en una sola llamada a `update-package-versions-status`.
El siguiente comando de ejemplo incluye un error en la actualización del estado de la versión provocado por una discordancia entre las versiones de un paquete. Ese error de actualización provoca que se omita otra llamada de actualización del estado de la versión.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo
--format npm --package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ=,4.0.0=E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc="
--versions 4.1.0 4.0.0 --target-status Archived
```
Código de salida de ejemplo:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "SKIPPED",
"errorMessage": "version 4.0.0 is skipped"
},
"4.1.0": {
"errorCode": "MISMATCHED_REVISION",
"errorMessage": "current revision: 25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=, expected revision: 25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ="
}
}
}
```
## Eliminación de las versiones de los paquetes
El estado `Disposed` del paquete tiene un comportamiento similar al de`Archived`, excepto que los activos del paquete se eliminarán permanentemente CodeArtifact para que el almacenamiento de activos ya no se facture a la cuenta del propietario del dominio. Para obtener más información sobre el estado de cada versión del paquete, consulte [El estado de la versión del paquete](packages-overview.md#package-version-status). Para cambiar el estado de una versión de paquete a `Disposed`, use el comando `dispose-package-versions`. Esta capacidad es independiente de la de `update-package-versions-status` debido a que la eliminación de una versión de paquete no es reversible. Como los activos del paquete se eliminarán, el estado de la versión no se puede volver a cambiar a `Archived`, `Unlisted` o `Published`. La única acción que se puede realizar en una versión de paquete que se ha eliminado es eliminarla mediante el comando `delete-package-versions`.
Para llamar a `dispose-package-versions` correctamente, la entidad principal de IAM que realiza la llamada debe tener el permiso `codeartifact:DisposePackageVersions` sobre el recurso del paquete.
El comportamiento del comando `dispose-package-versions` es similar a `update-package-versions-status`, incluido el comportamiento de las opciones `--version-revisions ` y `--expected-status` que se describen en las secciones de [revisión de versión](#update-status-specify-package-version-revision) y [estado esperado](#using-expected-status). Por ejemplo, el siguiente comando intenta eliminar la versión de un paquete, pero falla debido a un estado esperado que no coincide.
```
aws codeartifact dispose-package-versions —domain my_domain --domain-owner 111122223333
--repository my_repo --format npm --package chalk --versions 4.0.0
--expected-status Unlisted
```
Código de salida de ejemplo:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
Si se vuelve a ejecutar el mismo comando con un `--expected-status` de `Published`, la eliminación se realizará correctamente.
```
aws codeartifact dispose-package-versions —domain my_domain --domain-owner 111122223333
--repository my_repo --format npm --package chalk --versions 4.0.0
--expected-status Published
```
Código de salida de ejemplo:
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Disposed"
}
},
"failedVersions": {}
}
```
# Edición de los controles de origen de los paquetes
En AWS CodeArtifact, las versiones de los paquetes se pueden añadir a un repositorio publicándolas directamente, extrayéndolas de un repositorio anterior o incorporándolas desde un repositorio público externo. Permitir que las versiones en paquetes de un paquete se agreguen mediante publicación directa o ingesta desde repositorios públicos hace que sea vulnerable a un ataque de sustitución de dependencias. Para obtener más información, consulte [Ataques de sustitución de dependencias](dependency-substitution-attacks.md). Para protegerle de un ataque de sustitución de dependencias, puede configurar 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.
Cualquier equipo que desee permitir que las nuevas versiones de diferentes paquetes provengan tanto de fuentes internas, como la publicación directa, como de fuentes externas, como los repositorios públicos, debería considerar la posibilidad de configurar los controles de origen de los paquetes. 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. Para obtener información sobre la configuración del control de origen del paquete y sus valores predeterminados, consulte [Configuración de los controles de origen del paquete](#package-origin-control-settings).
Para eliminar el registro del paquete después de utilizar la operación de la API `put-package-origin-configuration`, utilice `delete-package` (consulte [Eliminar un paquete o una versión de un paquete](delete-package.md)).
## Escenarios comunes de control de acceso a paquetes
En esta sección se incluyen algunos escenarios comunes cuando se agrega una versión de paquete a un CodeArtifact repositorio. 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* es un paquete que se publica directamente desde un administrador de paquetes en su repositorio, como un paquete que usted o su equipo crean y mantienen. Un *paquete externo* es un paquete que existe en un repositorio público y que puede incorporarse a su repositorio mediante una conexión externa.
**Se publica una versión de paquete externo para un paquete interno existente**
En este escenario, consideremos un paquete interno, *packageA*. Tu equipo publica la primera versión del paquete del paquete A *en* un CodeArtifact repositorio. 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 que el paquete existe en tu repositorio, se publica un paquete con el mismo nombre en un repositorio público que está conectado a tu CodeArtifact repositorio. Podría tratarse de un intento de ataque de sustitución de dependencias contra el paquete interno, o podría ser simplemente 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 CodeArtifact repositorio con una conexión externa a un repositorio público. 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 CodeArtifact repositorio 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/codeartifact/latest/ug/images/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. O bien no conoce el paquete público y está intentando publicar un paquete no relacionado con el mismo nombre, o bien está intentando publicar una versión parcheada, o bien está intentando publicar directamente la versión exacta del paquete que ya existe externamente. CodeArtifact rechazará la versión que está intentando publicar, pero le permitirá anular el rechazo de forma explícita y publicar la versión si es necesario.
En la siguiente imagen, *RePoA* es tu CodeArtifact repositorio con una conexión externa a un repositorio público. Su repositorio contiene la versión 3.0 que ingirió del repositorio público. Quiere publicar la versión 1.1 en su repositorio. 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 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/codeartifact/latest/ug/images/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 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**. Su equipo decide que necesita 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**.
## 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.
**nota**
Los ajustes y los valores disponibles son diferentes cuando los controles de origen se configuran en los grupos de paquetes. Para obtener más información, consulte [Controles de origen de grupos de paquetes](package-group-origin-controls.md).
**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 CodeArtifact repositorios configurados como repositorios ascendentes o 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 CodeArtifact 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
La configuración predeterminada de los controles de origen de los paquetes se determina en función de la configuración de los controles de origen del grupo de paquetes asociado al paquete. Para obtener más información sobre los grupos de paquetes y los controles de origen de los grupos de paquetes, consulte [Trabajar con grupos de paquetes en CodeArtifact](package-groups.md) y [Controles de origen de grupos de paquetes](package-group-origin-controls.md).
Si un paquete está asociado a un grupo de paquetes con una configuración de restricción `ALLOW` para cada tipo de restricción, los controles de origen predeterminados de los paquetes se basarán en la forma en que se añada la primera versión de dicho paquete al repositorio.
+ 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**.
**nota**
**Los paquetes que existían en CodeArtifact los repositorios aproximadamente antes de mayo de 2022 tendrán los controles de origen predeterminados **Publish: ALLOW y Upstream: ALLOW.**** Los controles de origen de los paquetes deben configurarse manualmente para dichos paquetes. Desde entonces, los valores predeterminados actuales se han establecido en los paquetes nuevos y comenzaron a aplicarse cuando se lanzó la característica el 14 de julio de 2022. Para obtener más información sobre la configuración de los controles de origen de los paquetes, consulte [Edición de los controles de origen de los paquetes](#edit-package-origin-controls).
De lo contrario, si un paquete está asociado a un grupo de paquetes que tiene al menos una configuración de restricción `BLOCK` o `ALLOW_SPECIFIC_REPOSITORIES`, la configuración de los controles de origen predeterminada para ese paquete se definirá como **Publish: ALLOW** y **Upstream: ALLOW**.
## Cómo interactúan los controles de origen de los paquetes con los controles de origen de los grupos de paquetes
Como los paquetes y los grupos de paquetes tienen configuraciones de los controles de origen diferentes, es importante entender cómo interactúan ambas entre sí.
La interacción entre las dos configuraciones es que una configuración `BLOCK` prevalece sobre una configuración `ALLOW`. En la siguiente tabla se muestran algunos ejemplos de configuraciones y sus configuraciones efectivas de los controles de origen.
| Configuración de los controles de origen de los paquetes | Configuración de los controles de origen de los grupos de paquetes | Configuración efectiva de los controles de origen |
| --- | --- | --- |
| PUBLISH: ALLOWUPSTREAM: ALLOW | PUBLISH: ALLOWUPSTREAM: ALLOW | PUBLISH: ALLOWUPSTREAM: ALLOW |
| PUBLISH: BLOCKUPSTREAM: ALLOW | PUBLISH: ALLOWUPSTREAM: ALLOW | PUBLISH: BLOCKUPSTREAM: ALLOW |
| PUBLISH: ALLOWUPSTREAM: ALLOW | PUBLISH: ALLOWUPSTREAM: BLOCK | PUBLISH: ALLOWUPSTREAM: BLOCK |
Lo que esto significa es que un paquete con la configuración de origen **Publish: ALLOW** y **Upstream: ALLOW** está, en la práctica, quedando supeditado a la configuración de los controles de origen del grupo de paquetes asociado.
## 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 agrega la primera versión del paquete al repositorio; 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 los paquetes de un CodeArtifact repositorio, lleve a cabo los pasos del siguiente procedimiento.
**Para añadir o editar los controles de origen del paquete (consola)**
1. Abra la AWS CodeArtifact consola en [https://console.aws.amazon.com/codesuite/codeartifact/home](https://console.aws.amazon.com/codesuite/codeartifact/home).
1. En el panel de navegación, elija **Repositorios** y elija el repositorio que contiene 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, en **controles de Origin**, seleccione **Editar**.
1. En **Editar controles de origen**, seleccione los controles de origen del paquete que desea configurar para este paquete. Los dos ajustes de control de origen del paquete, Publish y Upstream, 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.**
**Para añadir o editar los controles de origen del paquete (AWS CLI)**
1. Si no lo has hecho, configúrala AWS CLI siguiendo los pasos que se indican en. [Configuración con AWS CodeArtifact](get-set-up-for-codeartifact.md)
1. Utilice el comando `put-package-origin-configuration` para añadir o editar los controles de origen de los paquetes. Sustituya los campos siguientes:
+ *my\$1domain*Sustitúyalo por el CodeArtifact dominio que contiene el paquete que deseas actualizar.
+ *my\$1repo*Sustitúyalo por el CodeArtifact repositorio que contiene el paquete que deseas actualizar.
+ *npm*Sustitúyalo por el formato de paquete que desee actualizar.
+ *my\$1package*Sustitúyalo por el nombre del paquete que desee actualizar.
+ Sustituya *ALLOW* y *BLOCK* por la configuración de control de origen del paquete que desee.
```
aws codeartifact put-package-origin-configuration --domain my_domain \
--repository my_repo --format npm --package my_package \
--restrictions publish=ALLOW,upstream=BLOCK
```
## Repositorios editoriales y originales
CodeArtifact no permite publicar versiones de paquetes que estén presentes en repositorios ascendentes o repositorios públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete de Maven `com.mycompany.mypackage:1.0` en un repositorio `myrepo` y `myrepo` tiene un repositorio ascendente con una conexión externa al central de Maven. Considere los siguientes escenarios.
1. Los ajustes de control de origen de los paquetes de `com.mycompany.mypackage` son **Publish: ALLOW y **Upstream: ALLOW****. Si `com.mycompany.mypackage:1.0` está presente en el repositorio principal o en Maven Central, CodeArtifact rechaza cualquier intento de publicación en `myrepo` él con un error de conflicto 409. Aún puede publicar una versión diferente, por ejemplo `com.mycompany.mypackage:1.1`.
1. Los ajustes de control de origen de los paquetes de `com.mycompany.mypackage` son **Publish: ALLOW y **Upstream: BLOCK****. Puede publicar en su repositorio cualquier versión de `com.mycompany.mypackage` 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 `com.mycompany.mypackage` son **Publish: BLOCK** y **Upstream: ALLOW**. No puede publicar ninguna versión del paquete directamente en su repositorio.