Paket-Registry

fremforge enthält eine integrierte Paket-Registry. Pakete liegen in deiner Organisation. Es gibt keine langlebigen Registry-Tokens: CI-Jobs verwenden den Token, den jeder Job in Forgejo Actions ohnehin bekommt, und Personen verwenden die fremforge-CLI, die jedem Tool einen Token gibt, der höchstens eine Stunde gilt.

Jede Registry wird von einem einzigen Host, frem.sh, ausgeliefert, unter einem Pfad pro Organisation und Pakettyp:

https://frem.sh/api/packages/<org>/<type>/

Es gibt keine eigenen Hostnamen pro Ökosystem. Container-Images sind die einzige Ausnahme von der Pfadregel: Sie verwenden die OCI-Registry direkt auf frem.sh.

Um öffentliche Images und Pakete (Docker Hub, quay.io, npm, PyPI, Maven Central, NuGet, Go-Module, crates.io und mehr) über deine Organisation zu ziehen, mit Caching, Verifizierung, optionalem Malware-Scanning und angewandter Paketrichtlinie, verwende den Abhängigkeits-Proxy.

Unterstützte Pakettypen

Die Pfade in der Tabelle sind relativ zu https://frem.sh/api/packages/<org>/. Container-Images und Go-Module sind die Ausnahmen und werden vollständig angegeben.

Jeder Typ in der Tabelle ist für jede Organisation eingeschaltet. Für Conda, CRAN, Conan, Chef, Pub, Swift, Vagrant, den Go-Modul-Proxy und generische Dateien gibt es auf dieser Seite noch keine Anleitung: Richte den Client auf den Pfad aus der Tabelle aus und authentifiziere dich wie für andere Pakettypen beschrieben.

Bei einer privaten Organisation antwortet jeder der obigen Pfade ohne Token mit 401, auch die Index- und Schlüsseldateien. Nur der NuGet-Dienstindex (nuget/index.json) ist ohne Token lesbar, weil der NuGet-Client ihn abruft, bevor er sich authentifiziert.

Authentifizierung

Es gibt drei Wege, dich zu authentifizieren:

Wer welches Paket lesen, veröffentlichen und löschen darf, regelt der Paketzugriff der Organisation, standardmäßig organisationsweit; Owner können ihn pro Paket einschränken und Namen schützen. Siehe Paketzugriff.

API-Tokens (ffp_…) werden von den Registrys nicht angenommen. Sie sind nur für die REST-API von fremforge gedacht. Persönliche Zugriffstokens mit Paket-Scopes werden nicht ausgestellt: Verwende einen Registry-Robot.

Aus Forgejo Actions veröffentlichen

Der automatische Token jedes Jobs kann die Registry des Owners seines Repositorys verwenden:

• Lesen: jedes Paket des Owners (der Organisation, zu der das Repository gehört).
• Schreiben: ein Paket, das mit dem eigenen Repository des Jobs verknüpft ist, oder ein neues Paket anlegen. Ein von einem Job angelegtes Paket wird automatisch mit dem Repository dieses Jobs verknüpft.
• Pull Requests aus Forks bekommen nur Lesezugriff, nie Schreibzugriff.

Du musst nichts deklarieren: Es gibt kein permissions: packages: write, das du ergänzen müsstest. Ein Schreibzugriff auf ein Paket, das mit einem anderen Repository verknüpft ist, oder auf ein Paket, das mit keinem Repository verknüpft ist, wird mit 403 abgelehnt:

forbidden: this job's token can only write packages linked to its own repository; npm package "@acme/ui" belongs to another repository

Für ein Paket mit Zugriff pro Paket kann ein Owner außerdem den Jobs eines anderen Repositorys Lese- oder Schreibzugriff auf genau dieses Paket geben (eine Actions-Freigabe); in einer privaten Organisation können Jobs von Repositorys ohne Freigabe oder Verknüpfung es dann nicht mehr lesen.

Um ein bestehendes, nicht verknüpftes Paket aus einem Job zu veröffentlichen, verknüpfe es zuerst auf der Seite Einstellungen des Pakets mit dem Repository.

Der Token funktioniert bei jedem Client als Passwort (mit beliebigem Benutzernamen) und bei npm als Bearer-Token. Ein Workflow, der jeden gängigen Typ veröffentlicht:

name: publish
on:
  push:
    tags: ['v*']

jobs:
  publish:
    runs-on: ubuntu-latest
    env:
      TOKEN: ${{ secrets.FORGEJO_TOKEN }}
      ORG: ${{ github.repository_owner }}
    steps:
      - uses: actions/checkout@v4

      - name: Container image
        run: |
          echo "$TOKEN" | docker login frem.sh -u "${{ github.actor }}" --password-stdin
          docker build -t "frem.sh/$ORG/app:${GITHUB_REF_NAME}" .
          docker push "frem.sh/$ORG/app:${GITHUB_REF_NAME}"

      - name: npm
        run: |
          printf '//frem.sh/api/packages/%s/npm/:_authToken=%s\n' "$ORG" "$TOKEN" >> "$HOME/.npmrc"
          npm publish

      - name: PyPI
        run: |
          python -m pip install build twine
          python -m build
          twine upload --repository-url "https://frem.sh/api/packages/$ORG/pypi" \
            -u "${{ github.actor }}" -p "$TOKEN" dist/*

      - name: Maven
        run: mvn --batch-mode deploy -s .ci/settings.xml
        env:
          FREMFORGE_USER: ${{ github.actor }}

.ci/settings.xml liest den Token aus der Umgebung und kann deshalb committet werden:

<settings>
  <servers>
    <server>
      <id>fremforge</id>
      <username>${env.FREMFORGE_USER}</username>
      <password>${env.TOKEN}</password>
    </server>
  </servers>
</settings>

Für Gradle übergibst du dieselben Werte als Properties, zum Beispiel -PfremforgeUsername="${{ github.actor }}" -PfremforgePassword="$TOKEN", und liest sie wie unter Gradle gezeigt.

Auf deinem Rechner: fremforge auth

Installiere die fremforge-CLI und melde dich an. Die Anmeldung läuft über das Single Sign-on und die MFA deiner Organisation:

fremforge auth login                 # opens a browser
fremforge auth login --device        # headless or SSH box: shows a code to approve in any
                                     # browser at https://frem.sh/_app/device

Die Geräteanmeldung braucht CLI 0.5.0 oder neuer.

Richte dann jedes Tool einmal ein:

fremforge auth configure docker pip npm maven gradle
# or in one go:
fremforge auth login --configure=docker,pip,npm,maven,gradle

Was configure pro Tool tut:

Der Helper und der keyring-Befehl sind kleine Skripte in ~/.local/bin (unter Windows %LOCALAPPDATA%\fremforge\bin), die die CLI aufrufen. configure warnt dich, wenn dieses Verzeichnis nicht in deinem PATH liegt.

Der Token wird automatisch erneuert. npm, Maven und Gradle können nicht nach einem frischen Token fragen, deshalb wird die Kopie in ihrer Konfiguration bei jedem fremforge-Befehl neu geschrieben, oder ausdrücklich mit:

fremforge auth refresh     # makes sure the written token is valid for at least 30 more minutes

Führe ihn vor einem Build aus, zum Beispiel als npm-Skript preinstall ("preinstall": "fremforge auth refresh --quiet") oder als Pre-Build-Schritt in der IDE.

Deine Anmeldung selbst (der Refresh-Token, 30 Tage gültig) wird im Schlüsselbund des Betriebssystems aufbewahrt: macOS-Schlüsselbund, Windows-Anmeldeinformationsverwaltung oder der Secret Service unter Linux. Wo es keinen Schlüsselbund gibt oder er sich nicht nutzen lässt, weicht die CLI auf ~/.config/fremforge/auth.json mit Modus 600 aus und sagt dir das. Die Schlüsselbund-Unterstützung unter macOS und Windows ist neu in 0.5.0 und bisher nur mit automatisierten Tests geprüft, nicht auf echten Rechnern; der Rückfall auf die Datei sorgt dafür, dass alles weiter funktioniert, wenn ein Schlüsselbund verweigert.

fremforge auth logout entfernt die Anmeldung und alle Zugangsdaten, die configure geschrieben hat: die Token-Zeilen für npm, Maven und Gradle, den credHelpers-Eintrag für docker sowie die Helper- und keyring-Skripte. Es entfernt nur, was fremforge geschrieben hat, erkennbar an einem Kommentar fremforge-managed, sodass deine eigenen Zeilen bleiben. Den Token auf dem Server kann es nicht widerrufen: Ein bereits ausgestellter Access-Token bleibt gültig, bis er abläuft, höchstens 1 Stunde. Um die Anmeldung sofort zu beenden, entferne fremforge-cli unter Autorisierte OAuth2-Anwendungen auf frem.sh/user/settings/applications.

Andere Pakettypen

Die CLI richtet docker, pip/uv, npm, Maven und Gradle ein. Für die anderen Clients auf dieser Seite (NuGet, Composer, RubyGems, Cargo, Helm, apt, dnf, apk, pacman und Go) gibt es noch keinen Helper: Veröffentliche sie aus Forgejo Actions, wo <token> in den Anleitungen unten ${{ secrets.FORGEJO_TOKEN }} und <username> ${{ github.actor }} ist.

npm

Lege eine Datei .npmrc im Wurzelverzeichnis deines Projekts an:

@<scope>:registry=https://frem.sh/api/packages/<org>/npm/

fremforge auth configure npm liefert den Token (siehe Authentifizierung); in Actions ergänzt du die _authToken-Zeile aus dem Workflow oben.

<scope> ist der npm-Scope deines Pakets. Er muss nicht dem Namen der Organisation entsprechen: Die Organisation acme zum Beispiel kann Pakete unter @acme-tools/* veröffentlichen.

Veröffentlichen:

npm publish

Installieren:

npm install @<scope>/package-name

Docker / OCI

Führe auf deinem Rechner einmal fremforge auth configure docker aus; ein docker login gibt es nicht. In Actions meldest du dich wie im Workflow oben mit dem Job-Token an.

Pushen und pullen:

docker push frem.sh/<org>/<image>:<tag>
docker pull frem.sh/<org>/<image>:<tag>

OCI-Artefakte mit oras

Die Registry speichert auch OCI-Artefakte, die keine Container-Images sind: SBOMs, WASM-Module, Richtlinienbündel, Signaturen und alles andere mit einem eigenen artifactType. Verwende oras 1.2 oder neuer. Melde dich mit einem Registry-Robot oder, in Actions, mit dem Job-Token an:

echo "<token>" | oras login frem.sh -u <username> --password-stdin

Pushe eine Dateimenge unter einem Tag, mit einem eigenen Artefakttyp und optional einem eigenen Config-Blob. Ohne --config schreibt oras die leere Config (application/vnd.oci.empty.v1+json):

oras push frem.sh/<org>/<name>:1.0.0 \
  --artifact-type application/vnd.example.module.v1 \
  --config config.json:application/vnd.example.config.v1+json \
  module.wasm:application/vnd.wasm.content.layer.v1+wasm \
  sbom.spdx.json:application/spdx+json

oras pull frem.sh/<org>/<name>:1.0.0 -o ./out
oras manifest fetch frem.sh/<org>/<name>:1.0.0

Hänge ein Artefakt wie eine SBOM an ein bestehendes Image an und liste auf, was angehängt ist:

oras attach frem.sh/<org>/<image>:<tag> --artifact-type application/spdx+json \
  sbom.spdx.json:application/spdx+json
oras discover frem.sh/<org>/<image>:<tag>
oras discover frem.sh/<org>/<image>:<tag> --artifact-type application/spdx+json

Das angehängte Manifest trägt ein subject, das auf das Image zeigt. Die Registry hat keinen Referrers-Endpunkt nach OCI 1.1 (/v2/<name>/referrers/<digest> antwortet mit 404), genau wie ghcr.io: oras weicht von selbst auf den Referrers-Tag sha256-<digest> aus, einen Index, den es bei jedem Anhängen aktuell hält. Jedes Tool, das dem Tag-Schema-Fallback von OCI 1.1 folgt, etwa cosign, liest ihn auf dieselbe Weise.

Fasse Artefakte in einem Index zusammen und kopiere einen Tag mit allem, was darunter liegt:

oras manifest index create frem.sh/<org>/<name>:1.0.0-bundle 1.0.0 1.0.0-sbom
oras copy --recursive frem.sh/<org>/<name>:1.0.0-bundle --to-oci-layout ./layout:bundle

Was für ein Artefakt gilt:

• Malware-Scan. Jeder hochgeladene Blob wird gescannt, ob tar oder nicht. Ein Blob mit einer Malware-Signatur wird beim Hochladen mit DENIED abgelehnt, und ein Artefakt lässt sich erst pullen, wenn seine Blobs gescannt sind. Siehe Malware-Scan.
• Image-Signaturrichtlinie. Ein Artefakt ist kein Container-Image. Ein Manifest, dessen Config keine Image-Config ist oder dessen Layer alle Signaturen, Attestierungen oder SBOMs sind, wird nicht von der Image-Signaturrichtlinie der Organisation geprüft, sodass oras pull und cosign verify auch unter enforce funktionieren. Dasselbe gilt für einen Index, dessen Einträge alle einen artifactType deklarieren: ein mit oras manifest index create erstelltes Bündel und den Referrers-Tag sha256-<digest>, den oras discover liest, egal welche Typen angehängt sind. Ein Image mit angehängtem Artefakt wird weiterhin am Image selbst geprüft, ebenso ein Image, das in einem solchen Index aufgeführt ist, wenn es per Digest gepullt wird.
• Schwachstellen-Scanning. Der tägliche Trivy-Scan überspringt Artefakte: Er scannt nur Container-Images.
• Unveränderliche Tags. Unter der Container-Tag-Richtlinie der Organisation (semver oder all, siehe Unveränderliche Releases) lässt sich ein eingefrorener Tag weder auf einen anderen Digest verschieben noch löschen, auch bei Artefakten. oras push schreibt die aktuelle Zeit in die Annotation org.opencontainers.image.created, sodass ein erneuter Push derselben Dateien einen neuen Digest erzeugt, den ein eingefrorener Tag ablehnt. Damit ein wiederholter Push idempotent ist, lege die Annotation fest: --annotation org.opencontainers.image.created=<timestamp>. Das Anhängen an ein Image hinter einem eingefrorenen Tag funktioniert: Der Anhang wird per Digest gepusht, und der Referrers-Tag sha256-<digest> ist kein Versions-Tag.
• Löschen. oras manifest delete frem.sh/<org>/<name>@<digest> braucht die eigene Anmeldung eines Admins der Organisation. Registry-Robots können veröffentlichen, aber nicht löschen.
• Zugriffsprotokoll und Audit. Pushes, Pulls, Ablehnungen und Löschungen von Artefakten werden wie Image-Operationen im Zugriffsprotokoll und im Audit-Log erfasst.

Maven

Füge das Distributions-Repository zu pom.xml hinzu:

<distributionManagement>
  <repository>
    <id>fremforge</id>
    <url>https://frem.sh/api/packages/<org>/maven</url>
  </repository>
</distributionManagement>

Um daraus zu installieren, füge dieselbe URL unter <repositories> mit derselben <id> hinzu.

Die Zugangsdaten kommen von fremforge auth configure maven, das den Server-Eintrag fremforge in ~/.m2/settings.xml schreibt, oder in Actions aus einer Settings-Datei, die den Job-Token liest (siehe Aus Forgejo Actions veröffentlichen).

Gradle

Deklariere das Repository und lies die Zugangsdaten aus den Properties, die fremforge auth configure gradle schreibt (oder die du in Actions mit -P übergibst):

repositories {
    maven {
        url = uri("https://frem.sh/api/packages/<org>/maven")
        credentials {
            username = providers.gradleProperty("fremforgeUsername").get()
            password = providers.gradleProperty("fremforgePassword").get()
        }
    }
}

NuGet

Registriere die Quelle:

dotnet nuget add source https://frem.sh/api/packages/<org>/nuget/index.json \
  --name fremforge \
  --username <username> \
  --password <token>

PyPI

Sag pip und uv auf deinem Rechner nach fremforge auth configure pip, dass sie keyring fragen sollen. Den Benutzernamen in der Index-URL verlangt pip; verwende deinen fremforge-Benutzernamen:

pip config set global.keyring-provider subprocess
pip install --index-url https://<username>@frem.sh/api/packages/<org>/pypi/simple/ package-name

UV_KEYRING_PROVIDER=subprocess \
  uv pip install --index-url https://<username>@frem.sh/api/packages/<org>/pypi/simple/ package-name

Veröffentliche aus Actions mit twine, wie im Workflow oben:

twine upload --repository-url https://frem.sh/api/packages/<org>/pypi -u <username> -p <token> dist/*

Composer

Füge das Repository zu composer.json hinzu:

{
  "repositories": [
    { "type": "composer", "url": "https://frem.sh/api/packages/<org>/composer" }
  ]
}

Füge die Zugangsdaten zu auth.json im Wurzelverzeichnis deines Projekts hinzu:

{
  "http-basic": {
    "frem.sh": {
      "username": "<username>",
      "password": "<token>"
    }
  }
}

Veröffentliche ein Paketarchiv. Der Query-Parameter version ist nötig, sofern die composer.json im Archiv keine setzt:

curl --user <username>:<token> -X PUT \
  --upload-file package.zip \
  "https://frem.sh/api/packages/<org>/composer?version=1.0.0"

RubyGems

Pushe ein Gem mit einem API-Schlüssel:

gem push --key fremforge \
  --host https://frem.sh/api/packages/<org>/rubygems \
  your-gem-0.1.0.gem

Cargo

Füge die Registry zu .cargo/config.toml hinzu:

[registries]
fremforge = { index = "sparse+https://frem.sh/api/packages/<org>/cargo/" }

Füge die Zugangsdaten zu ~/.cargo/credentials.toml hinzu:

[registries.fremforge]
token = "Bearer <token>"

Veröffentlichen:

cargo publish --registry fremforge

Go-Module

Go-Module werden direkt über die URL des Repositorys ausgeliefert:

go get frem.sh/<org>/<repo>@v1.2.3

Ist dein Go-Modul privat, kennzeichne es entsprechend, damit die Go-Toolchain den öffentlichen Proxy und die Prüfsummendatenbank überspringt:

export GOPRIVATE=frem.sh/<org>/*

GOPRIVATE ist die übliche Go-Umgebungsvariable dafür; sie schaltet mit einer Einstellung die Abfragen an GOPROXY und GOSUMDB für passende Pfade ab. Damit sich go get authentifizieren kann, braucht Git Zugangsdaten für frem.sh: in Actions den Checkout-Token, auf deinem Rechner deine normale Git-Anmeldung.

Helm

Helm-Charts lassen sich in zwei Formen speichern, und du kannst eine oder beide nutzen:

• Als OCI-Artefakte in der Container-Registry auf frem.sh, neben deinen Images: oci://frem.sh/<org>/<chart>.
• In einem klassischen Chart-Repository (index.yaml plus Chart-Archive) unter https://frem.sh/api/packages/<org>/helm.

Die beiden sind getrennte Speicher. Ein als OCI gepushtes Chart erscheint nicht in der klassischen index.yaml, und umgekehrt.

<username> und <token> sind wie unter Andere Pakettypen beschrieben.

Helm-Charts als OCI-Artefakte

Braucht Helm 3.8 oder neuer. Melde dich einmal an und pushe dann das gepackte Chart in die Organisation. Name und Version des Charts werden zu Repository und Tag:

echo "<token>" | helm registry login frem.sh -u <username> --password-stdin
helm package ./<chart>                                    # writes <chart>-1.0.0.tgz
helm push <chart>-1.0.0.tgz oci://frem.sh/<org>

Installiere oder pulle direkt aus der Registry; ein helm repo add gibt es für OCI nicht:

helm install my-release oci://frem.sh/<org>/<chart> --version 1.0.0
helm pull oci://frem.sh/<org>/<chart> --version 1.0.0

Das Chart wird als Container-Paket mit dem Namen <chart> gespeichert, erscheint also unter den Packages der Organisation bei deinen Images, und ein Pull davon durchläuft dasselbe Malware-Scan-Gate wie ein Image-Pull.

Um eine Chart-Version zu entfernen, lösche sie über die Paket-API, Typ container. Ein Push legt außerdem eine Version an, die nach dem Manifest-Digest benannt ist (sha256:…); lösche auch diese, sonst bleibt der Inhalt des Charts gespeichert.

Klassisches Helm-Chart-Repository

Veröffentliche ein gepacktes Chart:

curl --user <username>:<token> -X POST \
  --upload-file ./<chart>-1.0.0.tgz \
  https://frem.sh/api/packages/<org>/helm/api/charts

Ein erfolgreicher Upload antwortet mit 201.

Eine veröffentlichte Chart-Version lässt sich nicht überschreiben. Ein erneuter Upload derselben Version mit anderem Inhalt antwortet mit 409 und einer Meldung, die mit immutable package: beginnt und besagt, dass die Datei bereits veröffentlicht ist; nichts wird ersetzt. Um eine Änderung zu veröffentlichen, erhöhe version in Chart.yaml, packe das Chart neu und lade die neue Version hoch. Ein erneuter Upload des identischen Archivs, wie ihn ein wiederholter CI-Job macht, antwortet mit 201 und ändert nichts. Siehe Unveränderliche Releases.

Füge das Repository hinzu und installiere daraus. Bei einer privaten Organisation antwortet der Index ohne Token mit 401:

echo "<token>" | helm repo add fremforge https://frem.sh/api/packages/<org>/helm \
  --username <username> --password-stdin
helm repo update
helm search repo fremforge/ --versions
helm install my-release fremforge/<chart> --version 1.0.0

Entferne eine Version mit der Paket-API, Typ helm. Die Nummer einer gelöschten Version bleibt verbraucht: Ein erneuter Upload dieser Version, mit welchem Inhalt auch immer, antwortet mit 409.

Debian

Das Repository ist signiert. Sein öffentlicher Schlüssel liegt unter .../debian/repository.key:

sudo curl --user <username>:<token> \
  https://frem.sh/api/packages/<org>/debian/repository.key \
  -o /etc/apt/keyrings/fremforge-<org>.asc
echo "deb [signed-by=/etc/apt/keyrings/fremforge-<org>.asc] https://frem.sh/api/packages/<org>/debian <distribution> <component>" \
  | sudo tee /etc/apt/sources.list.d/fremforge.list

Bei einer privaten Organisation gibst du apt den Token in /etc/apt/auth.conf.d/fremforge.conf (machine frem.sh login <username> password <token>).

Veröffentliche eine .deb in eine Distribution und Komponente deiner Wahl:

curl --user <username>:<token> -X PUT \
  --upload-file package_1.0.0_amd64.deb \
  https://frem.sh/api/packages/<org>/debian/pool/<distribution>/<component>/upload

RPM

Füge das Repository hinzu. Die ausgelieferte .repo-Datei lässt gpgkey auf den Signaturschlüssel zeigen, sodass dnf die Pakete verifiziert:

sudo dnf config-manager --add-repo https://frem.sh/api/packages/<org>/rpm.repo

Bei einer privaten Organisation ergänzt du username=<username> und password=<token> im Abschnitt des Repositorys in /etc/yum.repos.d/.

Veröffentlichen:

curl --user <username>:<token> -X PUT \
  --upload-file package-1.0.0-1.x86_64.rpm \
  https://frem.sh/api/packages/<org>/rpm/upload

Alpine

Installiere den Signaturschlüssel und füge dann das Repository hinzu. <branch> und <repository> sind Namen, die du beim Veröffentlichen wählst, zum Beispiel v3.20 und main:

cd /etc/apk/keys && curl --user <username>:<token> -JO \
  https://frem.sh/api/packages/<org>/alpine/key
echo "https://<username>:<token>@frem.sh/api/packages/<org>/alpine/<branch>/<repository>" \
  >> /etc/apk/repositories

Veröffentlichen:

curl --user <username>:<token> -X PUT \
  --upload-file package-1.0.0-r0.apk \
  https://frem.sh/api/packages/<org>/alpine/<branch>/<repository>

Arch

Importiere den Signaturschlüssel und füge dann das Repository zu /etc/pacman.conf hinzu:

curl --user <username>:<token> -o fremforge.gpg \
  https://frem.sh/api/packages/<org>/arch/repository.key
sudo pacman-key --add fremforge.gpg
sudo pacman-key --lsign-key <key-id>

[<org>.frem.sh]
SigLevel = Required
Server = https://frem.sh/api/packages/<org>/arch/<repository>/$arch

Veröffentlichen:

curl --user <username>:<token> -X PUT \
  --upload-file package-1.0.0-1-x86_64.pkg.tar.zst \
  https://frem.sh/api/packages/<org>/arch/<repository>

Scannen von Container-Images

Jedes Container-Image in der Registry wird in einem täglichen Durchlauf mit Trivy gescannt. Die Ergebnisse erscheinen unter Sicherheit › Befunde › Container-Images. Siehe Scannen von Container-Images dazu, was gescannt wird und wie du Pulls blockierst, und Bösartige Pakete zur Malware-Prüfung von Images.

Aufbewahrung und Bereinigung

Pakete werden standardmäßig unbegrenzt aufbewahrt.

• Eine Version in der Oberfläche löschen: Detailseite des Pakets → Delete version.
• Über die API löschen: DELETE https://frem.sh/api/v1/packages/<org>/<type>/<name>/<version>
• Bereinigung in großem Umfang: Organisationsverwaltung → Pakete → Cleanup policies, Tags per Regex auswählen, die neuesten N Versionen behalten.

Speicherkontingent

Was der Abhängigkeits-Proxy zwischenspeichert, zählt neben deinen eigenen Paketen zu genau diesem Paket-Pool. Siehe Speichergrenzen und Kontingente.

Querverweise

• Sicherheit und Lieferkette, Konfiguration des Scannens von Container-Images
• CI-Runner, Pakete aus Workflow-Jobs veröffentlichen
• Öffentliche REST-API, Pakete programmatisch verwalten