Amazon CodeCatalyst ist nicht mehr offen für Neukunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter [Wie migriert man von CodeCatalyst](migration.md).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Pakete veröffentlichen und ändern
Ein *Paket* in CodeCatalyst ist ein Paket aus Software und Metadaten, das zur Auflösung von Abhängigkeiten und zur Installation der Software erforderlich ist. Eine Liste der unterstützten Paketformate in CodeCatalyst finden Sie unter[Veröffentlichen und teilen Sie Softwarepakete in CodeCatalyst](packages.md). Dieser Abschnitt enthält Informationen zum Veröffentlichen, Anzeigen und Löschen von Paketen und zum Aktualisieren des Status einer Paketversion.
**Topics**
+ [Pakete in einem CodeCatalyst Paket-Repository veröffentlichen](package-publishing.md)
+ [Details zur Paketversion anzeigen](working-with-packages-view.md)
+ [Löschen einer Paketversion](working-with-packages-delete.md)
+ [Den Status einer Paketversion aktualisieren](working-with-packages-update-version-status.md)
+ [Steuerelemente für den Paketursprung bearbeiten](package-origin-controls.md)
# Pakete in einem CodeCatalyst Paket-Repository veröffentlichen
Sie können Versionen aller unterstützten Pakettypen mithilfe von Paketmanager-Tools in einem CodeCatalyst Paket-Repository veröffentlichen. Die Schritte zum Veröffentlichen einer Paketversion lauten wie folgt:
**Um eine Paketversion in einem CodeCatalyst Paket-Repository zu veröffentlichen**
1. Falls nicht, [erstellen Sie ein Paket-Repository](packages-repositories-create.md).
1. Connect Sie Ihren Paketmanager mit Ihrem Paket-Repository. Anweisungen, wie Sie den npm-Paketmanager mit einem CodeCatalyst Paket-Repository verbinden, finden Sie unter[Konfiguration und Verwendung von npm](packages-npm-use.md).
1. Verwenden Sie Ihren verbundenen Paketmanager, um Ihre Paketversionen zu veröffentlichen.
**Contents**
+ [Veröffentlichungs- und Upstream-Repositorys](#package-publishing-upstreams)
+ [Private Pakete und öffentliche Repositorien](#package-publishing-upstreams-direct)
+ [Paket-Assets überschreiben](#package-publishing-overwrite-assets)
## Veröffentlichungs- und Upstream-Repositorys
In können Sie keine Paketversionen veröffentlichen CodeCatalyst, die in erreichbaren Upstream-Repositorys oder öffentlichen Repositorys vorhanden sind. Nehmen wir zum Beispiel an, Sie möchten ein npm-Paket in einem Paket-Repository veröffentlichen und es ist über ein Gateway-Repository`myrepo`, das als Upstream-Repository konfiguriert `myrepo` ist, mit npmjs.com verbunden. `lodash@1.0` Wenn im Upstream-Repository oder auf npmjs.com vorhanden `lodash@1.0` ist, CodeCatalyst lehnt es jeden Versuch ab, es in npmjs.com zu veröffentlichen, indem es einen 409-Konfliktfehler ausgibt. `myrepo` Dadurch wird verhindert, dass Sie versehentlich ein Paket mit demselben Namen und derselben Version wie ein Paket in einem Upstream-Repository veröffentlichen, was zu unerwartetem Verhalten führen kann.
Sie können immer noch verschiedene Versionen eines Paketnamens veröffentlichen, die in einem Upstream-Repository existieren. Wenn `lodash@1.0` es beispielsweise in einem Upstream-Repository vorhanden `lodash@1.1` ist, aber nicht, können Sie im Downstream-Repository veröffentlichen`lodash@1.1`.
## Private Pakete und öffentliche Repositorien
CodeCatalyst veröffentlicht keine in Repositorys gespeicherten Pakete in öffentlichen CodeCatalyst Repositorys wie npmjs.com oder Maven Central. CodeCatalyst importiert Pakete aus öffentlichen Repositorys in ein CodeCatalyst Repository, verschiebt Pakete jedoch nicht in die entgegengesetzte Richtung. Pakete, die Sie in CodeCatalyst Repositorys veröffentlichen, bleiben privat und sind nur für das CodeCatalyst Projekt verfügbar, zu dem das Repository gehört.
## Paket-Assets überschreiben
Sie können ein bereits vorhandenes Paket-Asset mit einem anderen Inhalt nicht erneut veröffentlichen. Nehmen wir beispielsweise an, Sie haben bereits ein Maven-Paket mit einem JAR-Asset veröffentlicht. `mypackage-1.0.jar` Sie können dieses Asset nur dann erneut veröffentlichen, wenn die Prüfsumme der alten und neuen Assets identisch ist. Um dasselbe Asset mit neuem Inhalt erneut zu veröffentlichen, löschen Sie zuerst die Paketversion. Der Versuch, denselben Asset-Namen mit anderem Inhalt erneut zu veröffentlichen, führt zu einem HTTP 409-Konfliktfehler.
Bei Paketformaten, die mehrere Assets unterstützen (Python und Maven), können Sie einer vorhandenen Paketversion jederzeit neue Assets mit unterschiedlichen Namen hinzufügen, vorausgesetzt, Sie verfügen über die erforderlichen Berechtigungen. Da npm und NuGet nur ein einzelnes Asset pro Paketversion unterstützen, müssen Sie eine veröffentlichte Paketversion zuerst löschen, um sie zu ändern.
Wenn Sie versuchen, ein bereits vorhandenes Objekt erneut zu veröffentlichen (z. B.`mypackage-1.0.jar`) und der Inhalt des veröffentlichten Elements und des neuen Elements identisch sind, ist der Vorgang erfolgreich, da der Vorgang idempotent ist.
# Details zur Paketversion anzeigen
Sie können die CodeCatalyst Konsole verwenden, um Details zu einer bestimmten Paketversion anzuzeigen.
**Um Details zur Paketversion anzuzeigen**
1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.
1. Wählen Sie auf der Seite **Paket-Repositorys** das Repository aus, das die Paketversion enthält, deren Details Sie anzeigen möchten.
1. Suchen Sie in der Tabelle **Pakete** nach der Paketversion. Sie können die Suchleiste verwenden, um Pakete nach Paketnamen und Format zu filtern. Wählen Sie das Paket aus der Liste aus.
1. Wählen Sie auf der Seite mit den **Paketdetails** die Option **Versionen** und dann die Version aus, die Sie anzeigen möchten.
# Löschen einer Paketversion
Sie können eine Paketversion auf der Seite mit den **Paketversionsdetails** in der CodeCatalyst Konsole löschen.
**Um eine Paketversion zu löschen**
1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.
1. Wählen Sie auf der Seite **Paket-Repositorys** das Repository aus, das die Paketversion enthält, die Sie löschen möchten.
1. Suchen Sie das Paket und wählen Sie es aus der Tabelle aus.
1. Wählen Sie auf der Seite mit den **Paketdetails** **Versionen** und wählen Sie die Version aus, die Sie löschen möchten.
1. Wählen Sie auf der Seite mit den **Paketversionsdetails** die Option **Versionsaktionen** und dann **Löschen** aus.
1. Geben Sie *Löschen* in das Textfeld ein und wählen Sie **Löschen**.
# Den Status einer Paketversion aktualisieren
Jede Paketversion in CodeCatalyst hat einen Status, der den aktuellen Status und die Verfügbarkeit der Paketversion beschreibt. Sie können den Status der Paketversion in der CodeCatalyst Konsole ändern. Weitere Hinweise zu den möglichen Statuswerten von Paketversionen und deren Bedeutung finden Sie unter[Status der Paketversion](#package-version-status).
**So aktualisieren Sie den Status einer Paketversion**
1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.
1. Wählen Sie auf der Seite **Paket-Repositorys** das Repository aus, das die Paketversion enthält, deren Status Sie aktualisieren möchten.
1. Suchen Sie das Paket und wählen Sie es aus der Tabelle aus.
1. Wählen Sie auf der Seite mit den **Paketdetails** die Option **Versionen** und dann die Version aus, die Sie anzeigen möchten.
1. Wählen Sie auf der Seite mit den **Paketversionsdetails** die Option **Aktionen** und dann **Liste aufheben**, **Archivieren** oder Löschen aus**.** Informationen zum Status der einzelnen Paketversionen finden Sie unter. [Status der Paketversion](#package-version-status)
1. Geben Sie den Bestätigungstext in das Textfeld ein und wählen Sie **dann Je nachdem, auf welchen Status Sie **aktualisieren,** die Liste** entfernen, **Archivieren** oder Löschen aus.
## Status der Paketversion
Die folgenden Werte sind für den Status der Paketversion möglich. Sie können den Status der Paketversion in der Konsole ändern. Weitere Informationen finden Sie unter [Den Status einer Paketversion aktualisieren](#working-with-packages-update-version-status).
+ **Veröffentlicht**: Die Paketversion wurde erfolgreich veröffentlicht und kann von einem Paketmanager angefordert werden. Die Paketversion wird in die Paketversionslisten aufgenommen, die an die Paketmanager zurückgegeben werden, z. B. in der Ausgabe von`npm view versions`. Alle Ressourcen der Paketversion sind im Repository verfügbar.
+ **Nicht fertiggestellt**: Der letzte Veröffentlichungsversuch wurde nicht abgeschlossen. Derzeit können nur Maven-Paketversionen den Status **Unfertig** haben. Dies kann der Fall sein, wenn der Client ein oder mehrere Elemente für eine Paketversion hochlädt, aber keine `maven-metadata.xml` Datei für das Paket veröffentlicht, die diese Version enthält.
+ **Nicht aufgeführt**: Die Paketversions-Assets können aus dem Repository heruntergeladen werden, aber die Paketversion ist nicht in der Liste der Versionen enthalten, die an die Paketmanager zurückgegeben werden. Bei einem npm-Paket enthält die Ausgabe von beispielsweise `npm view versions` nicht die Paketversion. Das bedeutet, dass die NPM-Abhängigkeitsauflösungslogik die Paketversion nicht auswählt, da die Version nicht in der Liste der verfügbaren Versionen erscheint. Wenn die Paketversion „**Nicht gelistet**“ jedoch bereits in einer `npm package-lock.json` Datei referenziert wird, kann sie trotzdem heruntergeladen und installiert werden, z. B. wenn sie ausgeführt wird. `npm ci`
+ **Archiviert**: Die Ressourcen der Paketversion können nicht heruntergeladen werden. Die Paketversion wird nicht in die Liste der Versionen aufgenommen, die an die Paketmanager zurückgegeben werden. Da die Ressourcen nicht verfügbar sind, wird die Nutzung der Paketversion durch Clients blockiert. Wenn der Build Ihrer Anwendung von einer Version abhängt, die auf **Archiviert** aktualisiert wurde, schlägt der Build fehl, es sei denn, die Paketversion wurde lokal zwischengespeichert. Sie können einen Paketmanager oder ein Build-Tool nicht verwenden, um eine **archivierte** Paketversion erneut zu veröffentlichen, da sie immer noch im Repository vorhanden ist. Sie können den Status der Paketversion jedoch in der Konsole wieder auf **Nicht gelistet** oder **Veröffentlicht** ändern.
+ **Verworfen**: Die Paketversion erscheint nicht in den Auflistungen, und die Inhalte können nicht aus dem Repository heruntergeladen werden. **Der Hauptunterschied zwischen „**Verworfen“** und „**Archiviert**“ besteht darin, dass bei einem Status von „Verworfen“ die Inhalte der Paketversion dauerhaft von gelöscht werden CodeCatalyst.** **Aus diesem Grund können Sie eine Paketversion nicht von „Verworfen“ in „**Archiviert**“, „**Nicht gelistet**“ oder „**Veröffentlicht**“ verschieben.** Die Paketversion kann nicht verwendet werden, da die Assets gelöscht wurden. Wenn eine Paketversion als **entsorgt** markiert wurde, wird Ihnen die Aufbewahrung der Paketressourcen nicht in Rechnung gestellt.
Zusätzlich zu den Status in der obigen Liste kann eine Paketversion auch gelöscht werden. Nach dem Löschen befindet sich eine Paketversion nicht mehr im Repository und Sie können diese Paketversion mit einem Paketmanager oder einem Build-Tool nach Belieben erneut veröffentlichen.
## Normalisierung von Paketnamen, Paketversion und Assetnamen
CodeCatalyst normalisiert Paketnamen, Paketversionen und Assetnamen, bevor sie gespeichert werden, was bedeutet, dass sich die Namen oder Versionen in denen CodeCatalyst möglicherweise von dem Namen oder der Version unterscheiden, die bei der Veröffentlichung des Pakets angegeben wurden. Weitere Informationen darüber, wie Namen und Versionen CodeCatalyst für jeden Pakettyp normalisiert werden, finden Sie in der folgenden Dokumentation.
+ [Normalisierung von Python-Paketnamen](python-name-normalization.md)
+ [NuGet Normalisierung von Paketnamen, Version und Assetnamen](nuget-name-normalization.md)
CodeCatalyst führt keine Normalisierung für andere Paketformate durch.
# Steuerelemente für den Paketursprung bearbeiten
In Amazon können Paketversionen zu einem Paket-Repository hinzugefügt werden CodeCatalyst, indem sie direkt veröffentlicht, aus einem Upstream-Repository heruntergeladen oder über ein Gateway aus einem externen, öffentlichen Repository aufgenommen werden. Wenn Sie zulassen, dass Versionen eines Pakets sowohl durch direkte Veröffentlichung als auch durch Aufnahme aus öffentlichen Repositorys hinzugefügt werden, sind Sie anfällig für Angriffe, die Abhängigkeiten ersetzen. Weitere Informationen finden Sie unter [Angriffe durch Substitution von Abhängigkeiten](#dependency-substitution-attacks). Um sich vor einem Angriff durch die Substitution von Abhängigkeiten zu schützen, konfigurieren Sie die Kontrolle über den Paketursprung für ein Paket in einem Repository, um einzuschränken, wie Versionen dieses Pakets dem Repository hinzugefügt werden können.
Sie sollten in Erwägung ziehen, die Kontrolle über die Herkunft von Paketen so zu konfigurieren, dass neue Versionen verschiedener Pakete sowohl aus internen Quellen wie Direktveröffentlichungen als auch aus externen Quellen wie öffentlichen Repositorien stammen. Standardmäßig werden die Kontrollen für den Paketursprung darauf konfiguriert, wie die erste Version eines Pakets zum Repository hinzugefügt wird.
## Einstellungen für die Kontrolle des Paketursprungs
Mit den Steuerelementen für den Paketursprung können Sie konfigurieren, wie Paketversionen zu einem Repository hinzugefügt werden können. Die folgenden Listen enthalten die verfügbaren Einstellungen und Werte für die Steuerung des Paketursprungs.
**Veröffentlichen**
Diese Einstellung konfiguriert, ob Paketversionen mithilfe von Paketmanagern oder ähnlichen Tools direkt im Repository veröffentlicht werden können.
+ **ZULASSEN**: Paketversionen können direkt veröffentlicht werden.
+ **BLOCK**: Paketversionen können nicht direkt veröffentlicht werden.
**Upstream**
Diese Einstellung konfiguriert, ob Paketversionen aus externen, öffentlichen Repositorys aufgenommen oder von Upstream-Repositorys beibehalten werden können, wenn dies von einem Paketmanager angefordert wird.
+ **ALLOW**: Jede Paketversion kann aus anderen CodeCatalyst Repositorys beibehalten werden, die als Upstream-Repositorys konfiguriert sind, oder aus einer öffentlichen Quelle mit einer externen Verbindung aufgenommen werden.
+ **BLOCKIEREN**: Paketversionen können nicht aus anderen CodeCatalyst Repositorys aufbewahrt werden, die als Upstream-Repositorys konfiguriert sind, oder von einer öffentlichen Quelle mit einer externen Verbindung aufgenommen werden.
### Standardeinstellungen für die Kontrolle des Paketursprungs
Die Standardkontrollen für den Paketursprung für ein Paket basieren darauf, wie die erste Version dieses Pakets dem Paket-Repository hinzugefügt wird.
+ Wenn die erste Paketversion direkt von einem Paketmanager veröffentlicht wird, lauten die Einstellungen **Publish: ALLOW und Upstream****: BLOCK**.
+ Wenn die erste Paketversion aus einer öffentlichen Quelle aufgenommen wurde, lauten die Einstellungen **Publish: BLOCK und **Upstream: ALLOW****.
## Allgemeine Szenarien zur Paketzugriffskontrolle
In diesem Abschnitt werden einige gängige Szenarien beschrieben, in denen eine Paketversion zu einem CodeCatalyst Paket-Repository hinzugefügt wird. Die Einstellungen zur Kontrolle des Paketursprungs werden für neue Pakete festgelegt, je nachdem, wie die erste Paketversion hinzugefügt wurde.
In den folgenden Szenarien wird ein *internes Paket* direkt von einem Paketmanager in Ihrem Repository veröffentlicht, z. B. ein Paket, das Sie verwalten. Ein *externes Paket* ist ein Paket, das in einem öffentlichen Repository vorhanden ist und über ein vorgelagertes Gateway-Repository in Ihr Repository aufgenommen werden kann.
**Eine externe Paketversion wird für ein vorhandenes internes Paket veröffentlicht**
Stellen Sie sich in diesem Szenario ein internes Paket, *PackageA*, vor. Ihr Team veröffentlicht die erste Paketversion für *PackageA in einem* Paket-Repository. CodeCatalyst Da dies die erste Paketversion für dieses Paket ist, werden die Einstellungen für die Kontrolle des Paketursprungs automatisch auf **Veröffentlichen: Zulassen und **Upstream:**** Blockieren gesetzt. Nachdem das Paket in Ihrem Repository veröffentlicht wurde, wird ein Paket mit demselben Namen in einem öffentlichen Repository veröffentlicht, das mit Ihrem CodeCatalyst Paket-Repository verbunden ist. Dies könnte ein versuchter Angriff zur Substitution von Abhängigkeiten auf das interne Paket sein, oder es könnte ein Zufall sein. Unabhängig davon sind die Kontrollen zur Paketherkunft so konfiguriert, dass sie die Aufnahme der neuen externen Version blockieren, um sich vor einem möglichen Angriff zu schützen.
In der folgenden Abbildung ist *RepoA* Ihr CodeCatalyst Paket-Repository mit einer Upstream-Verbindung zum Repository. `npm-public-registry-gateway` Ihr Repository enthält die Versionen 1.1 und 2.1 von *PackageA*, aber Version 3.0 ist im öffentlichen Repository veröffentlicht. Normalerweise würde *RepoA* Version 3.0 aufnehmen, nachdem das Paket von einem Paketmanager angefordert wurde. Da die Paketaufnahme auf **Blockieren** gesetzt ist, wird Version 3.0 nicht in Ihr CodeCatalyst Paket-Repository aufgenommen und steht den damit verbundenen Paketmanagern nicht zur Verfügung.
![\[Einfache Grafik, die zeigt, dass eine neue externe Paketversion aus einem öffentlichen Repository blockiert wird.\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png)
**Eine interne Paketversion wird für ein vorhandenes externes Paket veröffentlicht**
In diesem Szenario existiert ein Paket, *PackageB*, extern in einem öffentlichen Repository, das Sie mit Ihrem Repository verbunden haben. Wenn ein mit Ihrem Repository verbundener Paketmanager *PackageB* anfordert, wird die Paketversion aus dem öffentlichen Repository in Ihr Repository aufgenommen. **Da dies die erste Paketversion von *PackageB* ist, die zu Ihrem Repository hinzugefügt wurde, sind die Einstellungen für den Paketursprung auf **Publish: BLOCK und Upstream:** ALLOW konfiguriert.** Später versuchen Sie, eine Version mit demselben Paketnamen im Repository zu veröffentlichen. Möglicherweise kennen Sie das öffentliche Paket nicht und versuchen, ein nicht verwandtes Paket mit demselben Namen zu veröffentlichen, oder Sie versuchen möglicherweise, eine gepatchte Version zu veröffentlichen, oder Sie versuchen möglicherweise, genau die Paketversion, die bereits extern existiert, direkt zu veröffentlichen. CodeCatalyst lehnt die Version ab, die Sie zu veröffentlichen versuchen, aber Sie können die Ablehnung explizit außer Kraft setzen und die Version bei Bedarf veröffentlichen.
In der folgenden Abbildung ist *RepoA* Ihr CodeCatalyst Paket-Repository mit einer Upstream-Verbindung zum Repository. `npm-public-registry-gateway` Ihr Paket-Repository enthält Version 3.0, die es aus dem öffentlichen Repository aufgenommen hat. Sie möchten Version 1.2 in Ihrem Paket-Repository veröffentlichen. Normalerweise könnten Sie Version 1.2 in *RepoA* veröffentlichen, aber da die Veröffentlichung auf **Blockieren** eingestellt ist, kann Version 1.2 nicht veröffentlicht werden.
![\[Einfache Grafik, die zeigt, dass die Paketveröffentlichung blockiert ist.\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png)
**Veröffentlichen einer gepatchten Paketversion eines vorhandenen externen Pakets**
In diesem Szenario existiert ein Paket, *PackageB*, extern in einem öffentlichen Repository, das Sie mit Ihrem Paket-Repository verbunden haben. Wenn ein mit Ihrem Repository verbundener Paketmanager *PackageB* anfordert, wird die Paketversion aus dem öffentlichen Repository in Ihr Repository aufgenommen. **Da dies die erste Paketversion von *PackageB* ist, die zu Ihrem Repository hinzugefügt wurde, sind die Einstellungen für den Paketursprung auf **Publish: BLOCK und Upstream:** ALLOW konfiguriert.** Ihr Team beschließt, gepatchte Paketversionen dieses Pakets im Repository zu veröffentlichen. Um Paketversionen direkt veröffentlichen zu können, ändert Ihr Team die Einstellungen zur Kontrolle des Paketursprungs in **Publish: ALLOW** und **Upstream: BLOCK**. Versionen dieses Pakets können jetzt direkt in Ihrem Repository veröffentlicht und aus öffentlichen Repositorys aufgenommen werden. **Nachdem Ihr Team die gepatchten Paketversionen veröffentlicht hat, setzt Ihr Team die Einstellungen für den Paketursprung auf **Publish: BLOCK und Upstream: ALLOW** zurück.**
## Die Einstellungen für den Paketursprung werden bearbeitet
Die Kontrollen zur Paketherkunft werden automatisch konfiguriert, je nachdem, wie die erste Paketversion eines Pakets zum Paket-Repository hinzugefügt wird. Weitere Informationen finden Sie unter [Standardeinstellungen für die Kontrolle des Paketursprungs](#default-package-origin-control-settings). Gehen Sie wie folgt vor, um Steuerungen für den Paketursprung für ein CodeCatalyst Paket in einem Paket-Repository hinzuzufügen oder zu bearbeiten.
**Um Steuerelemente für den Paketursprung hinzuzufügen oder zu bearbeiten**
1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.
1. Wählen Sie das Paket-Repository aus, das das Paket enthält, das Sie bearbeiten möchten.
1. Suchen Sie in der Tabelle **Pakete** nach dem Paket, das Sie bearbeiten möchten, und wählen Sie es aus.
1. Wähle auf der Seite mit der Paketübersicht **Origin Controls** aus.
1. Wähle unter **Origin Controls** die Kontrollen für den Paketursprung aus, die du für dieses Paket einrichten möchtest. Beide Einstellungen zur Kontrolle des Paketursprungs, **Publish** und **Upstream**, müssen gleichzeitig festgelegt werden.
+ Um das direkte Veröffentlichen von Paketversionen zuzulassen, wählen Sie unter **Veröffentlichen** die Option **Zulassen** aus. Um die Veröffentlichung von Paketversionen zu blockieren, wählen Sie **Blockieren** aus.
+ **Um die Aufnahme von Paketen aus externen Repositorys und das Abrufen von Paketen aus Upstream-Repositorys zuzulassen, wählen Sie unter **Upstream-Quellen** die Option Zulassen aus.** **Um die gesamte Aufnahme und das Abrufen von Paketversionen aus externen und Upstream-Repositorys zu blockieren, wählen Sie Blockieren.**
1. Wählen Sie **Speichern**.
## Veröffentlichung und Upstream-Repositorys
In können Sie keine Paketversionen veröffentlichen CodeCatalyst, die in erreichbaren Upstream-Repositorys oder öffentlichen Repositorys vorhanden sind. Nehmen wir zum Beispiel an, Sie möchten ein npm-Paket in einem Repository veröffentlichen und `myrepo` haben ein Upstream-Repository mit einer externen Verbindung `lodash@1.0` zu npmjs.com. `myrepo` Stellen Sie sich die folgenden Szenarien vor.
1. Die Einstellungen für die Kontrolle des Paketursprungs `lodash` lauten **Publish: ALLOW** und **Upstream: ALLOW**. Wenn im Upstream-Repository oder auf npmjs.com vorhanden `lodash@1.0` ist, CodeCatalyst lehnt es jeden Versuch ab, in diesem Verzeichnis zu veröffentlichen, `myrepo` indem es einen 409-Konfliktfehler ausgibt. Sie könnten immer noch eine andere Version veröffentlichen, z. B. `lodash@1.1`
1. Die Einstellungen für die Kontrolle des Paketursprungs `lodash` lauten **Publish: ALLOW** und **Upstream: BLOCK**. Sie können jede Version von `lodash` in Ihrem Repository veröffentlichen, die noch nicht existiert, da Paketversionen nicht erreichbar sind.
1. Die Einstellungen zur Kontrolle des Paketursprungs `lodash` lauten **Publish: BLOCK** und **Upstream: ALLOW**. Sie können keine Paketversionen direkt in Ihrem Repository veröffentlichen.
## Angriffe durch Substitution von Abhängigkeiten
Paketmanager vereinfachen das Verpacken und Teilen von wiederverwendbarem Code. Bei diesen Paketen kann es sich um private Pakete handeln, die von einer Organisation zur Verwendung in ihren Anwendungen entwickelt wurden, oder es kann sich um öffentliche Pakete handeln, in der Regel Open-Source-Pakete, die außerhalb einer Organisation entwickelt und über öffentliche Paket-Repositorys verteilt werden. Bei der Anforderung von Paketen verlassen sich Entwickler auf ihren Paketmanager, um neue Versionen ihrer Abhängigkeiten abzurufen. Angriffe zur Substitution von Abhängigkeiten, auch bekannt als Dependency Confusion Attacks, nutzen die Tatsache aus, dass ein Paketmanager normalerweise keine Möglichkeit hat, legitime Versionen eines Pakets von bösartigen Versionen zu unterscheiden.
Angriffe zur Substitution von Abhängigkeiten gehören zu einer Untergruppe von Angriffen, die als Software-Supply-Chain-Angriffe bezeichnet werden. Ein Angriff auf die Software-Lieferkette ist ein Angriff, bei dem Sicherheitslücken überall in der Software-Lieferkette ausgenutzt werden.
Ein Angriff zur Substitution von Abhängigkeiten kann sich gegen jeden richten, der sowohl intern entwickelte Pakete als auch Pakete verwendet, die aus öffentlichen Repositorien abgerufen wurden. Die Angreifer identifizieren interne Paketnamen und platzieren dann strategisch bösartigen Code mit demselben Namen in öffentlichen Paket-Repositorys. In der Regel wird der bösartige Code in einem Paket mit einer hohen Versionsnummer veröffentlicht. Paketmanager rufen den bösartigen Code aus diesen öffentlichen Feeds ab, weil sie glauben, dass es sich bei den bösartigen Paketen um die neuesten Versionen des Pakets handelt. Dies führt zu einer „Verwechselung“ oder einer „Ersetzung“ zwischen dem gewünschten Paket und dem bösartigen Paket, was dazu führt, dass der Code kompromittiert wird.
Um Angriffe durch die Substitution von Abhängigkeiten zu verhindern, CodeCatalyst bietet Amazon Kontrollen zur Herkunft von Paketen. Kontrollen zur Paketherkunft sind Einstellungen, die steuern, wie Pakete zu Ihren Repositorys hinzugefügt werden können. Die Steuerelemente werden automatisch konfiguriert, wenn die erste Paketversion eines neuen Pakets zu einem CodeCatalyst Repository hinzugefügt wird. Sie können sicherstellen, dass Paketversionen nicht sowohl direkt in Ihrem Repository veröffentlicht als auch aus öffentlichen Quellen aufgenommen werden können, wodurch Sie vor Angriffen durch die Substitution von Abhängigkeiten geschützt sind. Weitere Informationen zu den Kontrollen zur Paketherkunft und zu deren Änderung finden Sie unter. [Steuerelemente für den Paketursprung bearbeiten](#package-origin-controls)