Avhengighetsproxy

Avhengighetsproxyen er en gjennomgående buffer (pull-through cache) for offentlige registre, som kjøres per organisasjon. Du peker docker, npm, pip, uv, dnf, Maven, NuGet, go, helm eller cargo mot organisasjonens proxysti på frem.sh, og fremforge henter fra det offentlige registeret på dine vegne:

• Den første pullen av et image-lag eller en pakkefil hentes fra upstream og kontrolleres mot upstreams egen hash. Hvis organisasjonen din slår på skanning etter skadevare, blir den også skannet med ClamAV mens den strømmes til deg. En fil som feiler en kontroll, blir aldri levert og aldri lagret.
• Senere pulls leveres fra fremforges lager i EU, for alle medlemmer av organisasjonen.
• Hvis upstream er nede, leveres den siste gode kopien. Tagger, npm-packumenter, PyPI-indekser, RPM repomd.xml, Maven maven-metadata.xml, NuGet-versjonslister og -registreringer, Go-versjonslister og @latest, Helm index.yaml-filer og Cargo-indeksfiler besvares fra den siste gode kopien med svarheaderen X-Fremforge-Proxy: stale. Se Brudd hos upstream.
• Organisasjonens pakkepolicy og kontrollene for ondsinnede pakker vurderes for pakker og imager som går gjennom proxyen, og hver pull registreres i tilgangsloggen for registeret. Siden 2026-10-11 blir en kjent ondsinnet pakke eller et kjent ondsinnet image avvist for alle organisasjoner, og en policy i modusen Enforce avviser det som bryter den; se Dette håndheves i dag.

Proxyen er skrivebeskyttet. Du kan ikke pushe til den.

Tilgjengelighet og aktivering

Proxyen er tilgjengelig i alle planer og er slått på som standard for alle organisasjoner. En eier av organisasjonen kan slå den av eller endre innstillingene under Bygg og utrulling › Avhengighetsproxy eller med API-et (et token med scopet policy:write):

curl -X PUT -H "Authorization: Bearer $FREMFORGE_TOKEN" -H 'Content-Type: application/json' \
  -d '{"enabled": true, "malware_scan": true}' \
  https://frem.sh/_app/api/v1/orgs/<org>/dependency-proxy

En organisasjon som aldri har lagret disse innstillingene, har standardoppsettet: proxyen er på, og hostede runnere puller gjennom den (se Hostede runnere). Når en eier har lagret dem, beholder organisasjonen nøyaktig det som ble lagret.

Skanning etter skadevare (malware_scan) er slått av som standard. Når den er på, skannes hvert image-lag, hver pakkefil og hvert chart organisasjonen din puller gjennom proxyen, med ClamAV, også når en annen organisasjon bufret det først uten å skanne det: den kopien skannes én gang, første gang en organisasjon som skanner, bruker den, og vurderingen gjelder deretter for alle. Pakkefiler og charts skannes før de leveres; for image-lag, se Containerimager. Kjente ondsinnede pakker (OSV-varsler av typen MAL-*) sjekkes for alle organisasjoner, uansett hva denne innstillingen sier. Den samme siden og det samme endepunktet setter block_until_scanned for containerimager, som krever at skanning etter skadevare er på (se Containerimager), og retention_days (7 til 365, standard 90; se Oppbevaring). En GET mot endepunktet viser om proxyen er på, forbruket ditt og taket ditt.

Autentisering

Bruk den samme legitimasjonen som for pakkeregisteret:

• Personer: et personlig tilgangstoken med read:package (eller det kortlivede tokenet fremforge auth gir verktøyene dine). Du må være medlem av organisasjonen.
• CI: jobbtokenet i Forgejo Actions. Et jobbtoken puller bare gjennom organisasjonen til sitt eget repository; alle andre organisasjoners proxyer avviser det. Jobber fra pull requests fra forker kan pulle, men aldri gjennom en upstream som bruker organisasjonens egen legitimasjon.
• Ekstern CI, byggeverter og pull secrets: en registerrobot med lesetilgang. Tokenet er en read:package-legitimasjon som alle andre.
• fremforges avhengighetsskanning: nåbarhetsanalysen leser npm-tarballer, PyPI-wheels og Maven-JAR-er gjennom organisasjonens proxy, på en intern rute som bare skannetjenesten når. Lisenssjekken, sjekken av utgivelsesalder og Go-modulgrafen leser registermetadata (npm, PyPI, Go, Maven Central, RubyGems og Packagist) på samme måte. Den er skrivebeskyttet, kan ikke brukes utenfra fremforge, og får pakkepolicyen, bufferen og lagringstaket ditt som alle andre pulls.

Hostede runnere

Som standard installerer jobber på runnere som fremforge drifter, gjennom organisasjonens proxy (runner_pull_through, på som standard). Ved hver jobbstart peker runneren npm, pip og uv mot proxyen, og også Go, Maven, NuGet og Trivys sårbarhetsdatabase for økosystemene som står i runner_pull_through_ecosystems (alle fire som standard). Jobben autentiserer seg med sitt eget jobbtoken, så hver installasjon passerer pakkepolicyen og skadevarekontrollene og står i tilgangsloggen din med jobbens repository. Hvis proxyen ikke kan nås når jobben starter, installerer jobben i stedet fra de offentlige registrene gjennom fremforges utgående proxy, og reserveløsningen logges. Sett runner_pull_through til false for å slå dette av. Se også Pakkebuffere.

Containerimager. For de samme jobbene puller jobbens Docker-daemon også containerimager gjennom organisasjonens proxy: docker pull, docker run, FROM i en Dockerfile, og jobb- og services:-containerne runneren starter. Ingenting i workflowen endres; imagenavnene forblir som de er (ghcr.io/..., quay.io/...), og hver pull bufres for organisasjonen din og registreres i tilgangsloggen.

• For alle organisasjoner: ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws og registry.access.redhat.com.
• Bare med organisasjonens egen legitimasjon: docker.io, registry.redhat.io og registry.connect.redhat.com går gjennom proxyen først når en eier har lagt inn organisasjonens legitimasjon for det registeret under Upstream-legitimasjon. Jobber fra pull requests fra forker bruker den aldri, så pullene deres fra disse registrene går direkte til registeret. Uten legitimasjon er pulls fra Docker Hub anonyme og underlagt Docker Hubs frekvensgrenser.
• Reserveløsning: proxyen sjekkes ved starten av hver jobb. Hvis den ikke kan nås, puller jobben hvert image direkte fra registeret, som før, og reserveløsningen logges. En enkelt pull som proxyen ikke kan levere, faller også gjennom til registeret.
• En buffer, ikke en sperre: for imager på denne veien faller en pull som pakkepolicyen eller skadevaresjekken avviser, også gjennom til registeret. Der en avvisning må stoppe pullen, puller du eksplisitt fra frem.sh/<org>/dependency-proxy/<registry>/<image> (nedenfor).
• Ikke dekket: en docker buildx-bygger som bruker driveren docker-container, kjører sin egen BuildKit og puller direkte. Standarddriveren docker går gjennom proxyen.

Containerimager

docker login frem.sh            # a token with read:package, as for the registry
docker pull frem.sh/<org>/dependency-proxy/<upstream>/<image>:<tag>

For eksempel:

docker pull frem.sh/acme/dependency-proxy/quay.io/prometheus/busybox:latest

I CI:

echo "$GITHUB_TOKEN" | docker login frem.sh -u x --password-stdin

Upstreams du kan pulle fra:

Alle andre verter avvises: proxyen henter aldri fra en vilkårlig URL.

Proxyen lister ikke et images tagger. Hostet Renovate foreslår likevel oppdateringer for et image du viser til via denne stien, for eksempel FROM frem.sh/<org>/dependency-proxy/docker.io/library/python:3.14-slim i en Dockerfile. Den slår opp nye tagger og digester hos upstream-registeret og skriver dem inn i referansen din, som beholder proxystien. Byggene dine fortsetter å pulle gjennom proxyen, så pull-sperrene nedenfor gjelder fortsatt.

Helm-charts som er lagret som OCI-artefakter hos disse upstreams, kommer gjennom den samme stien (Helm 3.8 eller nyere):

echo "$FREMFORGE_TOKEN" | helm registry login frem.sh -u <user or robot name> --password-stdin
helm pull oci://frem.sh/<org>/dependency-proxy/ghcr.io/prometheus-community/charts/prometheus --version 29.36.1

For charts i et klassisk Helm-repository (index.yaml), se Helm-charts.

En tag kontrolleres på nytt hos upstream høyst én gang i minuttet, med en HEAD-forespørsel, som Docker Hub ikke teller mot pull-grensen sin. Image-lag passerer de samme pull-sperrene som imager som er pushet til registeret ditt: med skanning etter skadevare slått på avvises infiserte lag og lag som ikke kan skannes; det samme gjelder imager over CVE-terskelen din hvis du har satt block_pull. Ondsinnede pakker inne i et image er dekket nedenfor. Som standard leveres et image mens lagene skannes. Med block_until_scanned svarer den første pullen av et image som ennå ikke er skannet, eller av et lag via digest, med 503 og Retry-After til skanningen er ferdig, vanligvis i løpet av sekunder. Et lag som en skanning har funnet infisert, avvises for alle organisasjoner.

Mens én forespørsel henter og skanner et lag, venter andre pulls av det samme laget på den. Hvis det tar lenger enn omtrent fire minutter, får de 503 med Retry-After: 30 (this layer is still being fetched and malware-scanned by another request), og et nytt forsøk leveres når laget er lagret. En skanning som går ut på tid, er ikke en vurdering: laget holdes tilbake, som for et lag som ikke kan skannes, men ingen vurdering registreres. Det settes i kø for fremforges bakgrunnsskanner for lag, som har lengre tid til rådighet, og en senere pull leveres når den skanningen er bestått.

En pakkefil der skanningen går tom for tid (npm, PyPI, RPM, Maven, NuGet, Go, Cargo eller et Helm-chart), behandles på samme måte: den forespørselen avvises, det registreres ikke noe resultat, og filen settes i kø for den samme bakgrunnsskanneren. En senere forespørsel leveres når den skanningen er bestått, eller avvises hvis den finner filen infisert. En RPM forblir organisasjonens egen mens den venter: den lagres og skannes bare i organisasjonens eget område, og en annen organisasjon som henter den samme RPM-en, henter og skanner sin egen kopi.

Størrelsesgrenser. Proxyen leverer ikke lag eller filer større enn 10 GiB (403). ClamAV leser høyst 4 GiB av én fil, så med skanning etter skadevare slått på kan et større lag eller en større fil ikke skannes fullt ut og holdes tilbake, unntatt et modell-lag i formatet safetensors eller GGUF som består formatkontrollen (se Modellskanning).

Ondsinnede pakker inne i bufrede imager

Språkpakkene inne i hvert image organisasjonen din bufrer (npm-, PyPI-, Maven-, Go-, crates-, RubyGems-, NuGet-, Packagist-, Pub- og Hex-pakker), sjekkes mot OSVs varsler om ondsinnede pakker (MAL-*), den samme sjekken som kjøres på imagene du pusher:

• etter at imaget er bufret første gang, vanligvis i løpet av neste skannesyklus (omtrent 15 minutter), og
• igjen hver dag, slik at et varsel som publiseres etter at du pullet imaget, likevel blir funnet.

Et treff er et kritisk funn under Sikkerhet › Funn › Avhengigheter › Skadevare, oppført som et image med navnet <org>/dependency-proxy/<upstream>/<repository> og digesten som inneholder det, og det sendes til dem som mottar sikkerhetsvarslene dine. Avvisning fungerer som for alle skadevarefunn, med en begrunnelse og en valgfri sluttdato. Funnet lukkes av seg selv når organisasjonen ikke lenger bufrer imaget, for eksempel etter at oppbevaringstiden har fjernet det.

En pull av et image med et åpent funn som ikke er avvist, avvises med 403 DENIED, som for pushede imager, og logges i tilgangsloggen som blocked med årsaken image_malware. Avvist siden 2026-10-11; før det ble en slik pull levert og registrert som would_block.

Upstream-legitimasjon

Docker Hub (docker.io) og Red Hat-registrene (registry.redhat.io og registry.connect.redhat.com, Red Hats sertifiserte partnerimager) pulles gjennom avhengighetsproxyen bare med organisasjonens egen konto. For GitHub (ghcr.io) og Quay (quay.io) er legitimasjon valgfri: uten den pulles de anonymt, noe som gir offentlige imager; legg til legitimasjon for å pulle de private imagene dine. En eier av organisasjonen legger inn legitimasjonen under Bygg og utrulling › Avhengighetsproxy › Påloggingsdetaljer for upstream, eller med API-et på /_app/api/v1/orgs/<org>/dependency-proxy/upstreams. Godtatte former:

• Docker Hub: brukernavnet ditt og et personlig tilgangstoken, eller et tilgangstoken for organisasjonen med navnet på Docker-organisasjonen som brukernavn.
• Red Hat: en tjenestekonto for registeret (et brukernavn som 1234567|ci, pluss tokenet), eller OpenShift-pull-secreten. Legg den inn én gang per Red Hat-register du puller fra; hvert av dem beholder bare sin egen oppføring fra pull-secreten.
• GitHub (ghcr.io): GitHub-brukernavnet ditt og et personlig tilgangstoken (classic) med read:packages.
• Quay (quay.io): en robotkonto (organisation+robot) og tokenet, eller quay.io-oppføringen i en Red Hat-pull-secret.

Red Hat-registrene med din legitimasjon, og private imager på ghcr.io og quay.io, er støttet, men ennå ikke verifisert fra ende til ende: fremforge har testet dem mot registrenes tokenflyt, men har ingen konto å pulle med.

Når en legitimasjon for ghcr.io eller quay.io er lagret, bruker hver pull fra det registeret den, også for offentlige imager, og bufres bare for organisasjonen din. Jobber fra pull requests fra forker bruker den aldri: de puller de to registrene anonymt, så de får bare offentlige imager.

Secreten lagres kryptert og brukes bare av avhengighetsproxyen, for organisasjonens egne pulls. Den vises aldri igjen; du ser et fingeravtrykk i stedet. Test connection kontrollerer den og viser, for Docker Hub, hvor mange pulls som er igjen i det gjeldende grensevinduet.

Imager som pulles med legitimasjonen din, bufres bare for organisasjonen din og leveres aldri til en annen organisasjon. Jobber fra pull requests fra forker kan ikke pulle gjennom et register som krever legitimasjonen din. Hvis legitimasjonen utløper, fortsetter imager som allerede er bufret, å bli levert, og statusen viser Avvist av registeret. Uten legitimasjon avvises en pull fra Docker Hub med en melding som sier det.

Kubernetes og OpenShift

Pek et speil mot proxyen. containerd, i /etc/containerd/certs.d/quay.io/hosts.toml:

server = "https://quay.io"

[host."https://frem.sh/v2/<org>/dependency-proxy/quay.io"]
  capabilities = ["pull", "resolve"]
  override_path = true

OpenShift, med et ImageTagMirrorSet (og et ImageDigestMirrorSet for digester):

apiVersion: config.openshift.io/v1
kind: ImageTagMirrorSet
metadata:
  name: frem-sh-dependency-proxy
spec:
  imageTagMirrors:
    - source: quay.io
      mirrors:
        - frem.sh/<org>/dependency-proxy/quay.io

Klyngens pull secret trenger et frem.sh-token med read:package.

npm

.npmrc i prosjektet eller hjemmekatalogen din:

registry=https://frem.sh/_app/proxy/<org>/npm/
//frem.sh/_app/proxy/<org>/npm/:_authToken=${FREMFORGE_TOKEN}

Bruk deretter npm, pnpm eller yarn som vanlig. Pakkene kommer fra registry.npmjs.org, også scopede pakker. Hver tarball må stemme med integrity (sha512) som npm-registeret publiserer for den, før den leveres.

npm audit og pnpm audit fungerer mot proxyen. De besvares fra fremforges egen kopi av OSV-varseldatabasen, så avhengighetslisten din sendes ikke til noen tredjeparts varseltjeneste. Støttede klienter og svarformatet er beskrevet under npm audit og pnpm audit gjennom avhengighetsproxyen.

For å kombinere proxyen med pakker organisasjonen publiserer i sitt eget register, sender du scopet ditt til registeret og alt annet til proxyen:

registry=https://frem.sh/_app/proxy/<org>/npm/
@<your-scope>:registry=https://frem.sh/api/packages/<org>/npm/
//frem.sh/_app/proxy/<org>/npm/:_authToken=${FREMFORGE_TOKEN}
//frem.sh/api/packages/<org>/npm/:_authToken=${FREMFORGE_TOKEN}

PyPI

pip install --index-url "https://<user>:${FREMFORGE_TOKEN}@frem.sh/_app/proxy/<org>/pypi/simple/" requests
uv pip install --index-url "https://<user>:${FREMFORGE_TOKEN}@frem.sh/_app/proxy/<org>/pypi/simple/" requests

Eller i pip.conf / uv.toml, med legitimasjonen i en netrc-fil eller et nøkkelringlager i stedet for i URL-en. Indeksen leveres i begge formatene installasjonsverktøyene bruker (PEP 503 HTML og PEP 691 JSON), med sha256, requires-python, yank-status og PEP 658-metadata for hver fil. Hver fil må stemme med sha256-verdien PyPI oppgir for den, før den leveres.

Bruk proxyen som eneste indeks. Ikke legg den til med --extra-index-url (eller PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL) ved siden av en annen indeks, eller en annen indeks ved siden av den: blandede indekser er det som gjør angrep med avhengighetsforveksling mulig, fordi installasjonsverktøyet tar et navn fra den indeksen som tilbyr det. For å installere pakker organisasjonen publiserer i sitt eget register, kjører du en separat installasjon med det registeret som eneste indeks og --no-deps, eller, med uv, låser du hver av dem til det med navn (explicit = true og [tool.uv.sources]).

RPM (dnf og yum)

Hvert repository nås på

https://frem.sh/_app/proxy/<org>/rpm/<upstream>/<repository path>

I dag er upstream cdn-ubi.redhat.com, Red Hats repositoryer for Universal Base Image (UBI 8, 9 og 10: BaseOS, AppStream og CodeReady Builder, for alle arkitekturer Red Hat publiserer), under content/public/ubi/. De krever ingen Red Hat-konto. En .repo-fil for UBI 9 på x86_64:

[ubi-9-baseos-fremforge]
name=UBI 9 BaseOS through fremforge
baseurl=https://frem.sh/_app/proxy/<org>/rpm/cdn-ubi.redhat.com/content/public/ubi/dist/ubi9/9/x86_64/baseos/os
username=<user or robot name>
password=<token with read:package>
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

[ubi-9-appstream-fremforge]
name=UBI 9 AppStream through fremforge
baseurl=https://frem.sh/_app/proxy/<org>/rpm/cdn-ubi.redhat.com/content/public/ubi/dist/ubi9/9/x86_64/appstream/os
username=<user or robot name>
password=<token with read:package>
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

dnf sender username og password som HTTP Basic-autentisering. Bruk en registerrobot for byggeverter og bygging av imager, og la filen bare være lesbar for root (chmod 600), fordi den inneholder tokenet. I et containerbygg slår du av imagets egne repositoryer for installasjonen (dnf --disablerepo='*' --enablerepo='*-fremforge' install …), slik at ingenting hentes utenom proxyen.

Dette gjør proxyen:

• repodata/repomd.xml kontrolleres på nytt hos upstream høyst hvert 5. minutt og leveres nøyaktig slik upstream publiserte den. En ny repomd.xml godtas først når primary.xml som den viser til, er lastet ned og stemmer med sha256-verdien og størrelsen repomd.xml oppgir for den. Inntil da, og mens upstream er nede, leveres den forrige.
• Metadatafiler for repositoryet (primary, filelists, other, updateinfo, modules, comps og sqlite-variantene) må stemme med sha256-verdien og størrelsen i repomd.xml.
• Pakker må stemme med sha256-verdien og størrelsen i primary.xml. Med skanning etter skadevare slått på skannes hver pakke også inne i den komprimerte nyttelasten, ikke bare som fil, og installasjonsskriptene skannes også. En pakke som skanneren ikke kan åpne, avvises da i stedet for å leveres uskannet.
• Pakkesignaturer kontrolleres av dnf selv (gpgcheck=1) mot Red Hats nøkkel, nøyaktig som uten proxyen. Proxyen endrer aldri en pakke eller metadataene for repositoryet.
• RPM-innhold bufres bare for organisasjonen din. En annen organisasjon som puller den samme pakken, henter og lagrer sin egen kopi. Det er slik at den samme kodestien senere kan levere Red Hat-innhold hentet med ditt eget Red Hat-abonnement, som aldri må nå en annen kunde.

Et repository som bruker noe annet enn sha256 til sjekksummer, leveres ikke. Proxying av cdn.redhat.com med Red Hat-rettighetssertifikatet ditt er planlagt og ennå ikke tilgjengelig.

Maven

Maven Central nås på

https://frem.sh/_app/proxy/<org>/maven/central/

Gjør den til speil for alle repositoryer i ~/.m2/settings.xml (eller den settings.xml bygget ditt bruker), med legitimasjonen i en <server> med samme id:

<settings>
  <servers>
    <server>
      <id>fremforge-proxy</id>
      <username><user or robot name></username>
      <password>${env.FREMFORGE_TOKEN}</password>
    </server>
  </servers>
  <mirrors>
    <mirror>
      <id>fremforge-proxy</id>
      <name>Maven Central through fremforge</name>
      <url>https://frem.sh/_app/proxy/<org>/maven/central/</url>
      <mirrorOf>*</mirrorOf>
    </mirror>
  </mirrors>
</settings>

Maven sender brukernavnet og passordet som HTTP Basic-autentisering når proxyen ber om dem. For å bruke proxyen sammen med pakker organisasjonen publiserer i sitt eget register, skriver du <mirrorOf>*,!fremforge</mirrorOf> og angir registeret ditt (https://frem.sh/api/packages/<org>/maven) som repositoryet fremforge med sin egen <server>.

Gradle (settings.gradle.kts):

dependencyResolutionManagement {
    repositories {
        maven {
            url = uri("https://frem.sh/_app/proxy/<org>/maven/central/")
            credentials {
                username = providers.environmentVariable("FREMFORGE_USER").get()
                password = providers.environmentVariable("FREMFORGE_TOKEN").get()
            }
        }
    }
}

Dette gjør proxyen:

• maven-metadata.xml kontrolleres på nytt hos Maven Central høyst hvert 5. minutt. En ny kopi godtas bare når den stemmer med Maven Centrals egen .sha1 for den. Inntil da, og mens Maven Central er nede, leveres den forrige kopien. .sha1, .md5, .sha256 og .sha512 for den beregnes fra kopien du får levert, så de stemmer alltid med den.
• Artefakter (jar-filer, POM-er, .module-filer og alle andre filer i en utgivelse) må stemme med Maven Centrals .sha1 og, når Maven Central publiserer en, .sha256. En fil uten noen av sjekksummene hentes ikke. Med skanning etter skadevare slått på skannes hver fil mens den strømmes til deg. En jar-fil åpnes også: en oppføring som skanneren ikke kan pakke ut selv (zstd), pakkes ut for den, og en jar-fil med en oppføring som ingen av dem kan åpne (for eksempel LZMA), avvises i stedet for å leveres uskannet.
• Last-Modified er tidspunktet Maven Central publiserte filen, også når den kommer fra bufferen, slik at Renovates minste utgivelsesalder og andre verktøy som leser den, ser det faktiske utgivelses- tidspunktet. En fil Maven Central sendte uten en slik header, får ingen Last-Modified i det hele tatt, aldri tidspunktet fremforge bufret den. En HEAD mot en hvilken som helst bufret fil svarer 200 med Content-Length og denne Last-Modified.
• Sjekksumfiler (.sha1, .sha256, …) og signaturer (.asc) for artefakter sendes videre uendret. Kontroller signaturene med PGP-pluginen i bygget ditt, slik du ville gjort uten proxyen.
• Snapshots leveres ikke. Maven Central publiserer ingen, og et snapshot kan endres under samme versjon. En -SNAPSHOT-forespørsel besvares med 404, så bygget ditt går videre til repositoryet som har den.

For pakkepolicyen heter en Maven-pakke groupId:artifactId. Utgivelsestidspunktet er når Maven Central publiserte filen, og lisensen er <licenses> som POM-en oppgir. En lisens som arves fra en overordnet POM, slås ikke opp, så den regnes som ikke vurdert.

NuGet

Pakkekilden er proxyens tjenesteindeks:

https://frem.sh/_app/proxy/<org>/nuget/v3/index.json

nuget.config ved siden av løsningen din:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="fremforge" value="https://frem.sh/_app/proxy/<org>/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <fremforge>
      <add key="Username" value="<user or robot name>" />
      <add key="ClearTextPassword" value="%FREMFORGE_TOKEN%" />
    </fremforge>
  </packageSourceCredentials>
</configuration>

<clear /> gjør proxyen til eneste kilde, så ingen pakke hentes utenom den. NuGet ekspanderer %FREMFORGE_TOKEN% fra miljøet, så tokenet trenger ikke stå i filen. Bruk deretter dotnet restore, dotnet add package <id> --version <version> eller nuget install som vanlig.

Dette gjør proxyen:

• Tjenesteindeksen viser bare ressurser på frem.sh: pakkeinnholdet (flat container) og pakkeregistreringen. Søk tilbys ikke, fordi restore og install ikke trenger det. dotnet add package uten --version trenger søk, så oppgi versjonen.
• Versjonslister og registreringer kontrolleres på nytt hos nuget.org høyst hvert 5. minutt, og den siste gode kopien leveres mens nuget.org er nede.
• Pakker (.nupkg) må stemme med SHA-512-verdien og størrelsen som katalogen til nuget.org registrerer for utgivelsen, før de leveres. En utgivelse der katalogoppføringen ikke har noen hash, blir ikke hentet. Med skanning etter skadevare slått på skannes hver pakke mens den strømmes til deg, både inne i pakken og som fil.
• Pakkesignaturer kontrolleres av NuGet-klienten selv, nøyaktig som uten proxyen. Proxyen endrer aldri en pakke.

For pakkepolicyen heter en NuGet-pakke det samme som ID-en med små bokstaver. Utgivelsestidspunktet og lisensen er published-datoen hos nuget.org og lisensuttrykket pakken oppgir. En pakke som oppgir lisensen som en fil eller en URL, regnes som ikke vurdert.

Go-moduler

export GOPROXY=https://frem.sh/_app/proxy/<org>/go
export GOSUMDB=sum.golang.org      # the default; keep it on

Autentiseringen kommer fra ~/.netrc (_netrc på Windows), som go-kommandoen leser for frem.sh. La filen bare være lesbar for deg (chmod 600 ~/.netrc):

machine frem.sh
login <user or robot name>
password <token with read:package>

Bruk GOPROXY=https://frem.sh/_app/proxy/<org>/go i stedet for å legge til ,direct: med direct hentes en modul som proxyen ikke leverer, fra kilderepositoryet sitt utenom proxyen.

Dette gjør proxyen:

• @v/list og @latest kontrolleres på nytt hos proxy.golang.org høyst hvert 5. minutt, og den siste gode kopien leveres mens den er nede.
• .mod og .zip må stemme med h1:-hashene som Gos sjekksumdatabase (sum.golang.org) har signert for den modulversjonen. Proxyen verifiserer databasens signatur med den samme nøkkelen som er innebygd i go-kommandoen. En modul-zip pakkes ut og hashes på samme måte som go-kommandoen hasher den, før den leveres. En modul som sjekksumdatabasen ikke kjenner, leveres ikke. Med skanning etter skadevare slått på skannes hver zip mens den strømmes til deg.
• Sjekksumdatabasen nås også gjennom proxyen. go-kommandoen spør proxyen om den leverer sum.golang.org, og henter deretter hvert oppslag og hver flis gjennom den. Derfor forblir GOSUMDB på og gjør fortsatt sin egen fullstendige verifisering, inkludert bevisene som proxyen selv ikke gjentar, og maskinen din trenger ingen direkte tilgang til sum.golang.org.
• Private moduler leveres ikke: proxy.golang.org kan ikke hente dem, og sjekksumdatabasen kjenner dem ikke. Unnta dem med GOPRIVATE (eller GONOPROXY og GONOSUMDB), så henter go-kommandoen dem fra din egen Git-hosting som før.
• Google blir aldri spurt om moduler som ligger på frem.sh. En forespørsel om en modul under frem.sh (eller et underdomene) avvises med 404 før proxyen kontakter noen, fordi selve forespørselen ville fortalt proxy.golang.org og sum.golang.org modulens sti. Legg frem.sh i GOPRIVATE, slik at go-kommandoen henter de modulene direkte fra frem.sh.

Hva som når Google for offentlige moduler

Proxyen henter offentlige Go-moduler fra Googles modulspeil (proxy.golang.org) og kontrollerer dem mot Googles sjekksumdatabase (sum.golang.org). Når en modul eller versjon ennå ikke er bufret, mottar Google derfor:

• modulstien og versjonen som hentes (for eksempel github.com/gorilla/websocket@v1.5.0), og oppslagene i sjekksumdatabasen for den;
• forespørsler fra fremforges utgående adresser, ikke fra maskinene dine, uten organisasjonens navn, bruker, token eller repository.

Google mottar ikke koden din, go.mod, navnene på repositoryene dine eller hvilken organisasjon som spurte. En modul som allerede er bufret, leveres uten å kontakte Google. Det samme gjelder sikkerhetsskannerne: de leser offentlige Go-moduler gjennom denne proxyen, og de spør aldri etter en modul som er privat etter reglene nedenfor.

For pakkepolicyen heter en Go-modul det samme som modulstien. Utgivelsestidspunktet er tidspunktet proxy.golang.org registrerer for versjonen. Go-moduler oppgir ingen lisens som proxyen kan lese, så lisensregler gjelder ikke for dem.

Helm-charts

Klassiske Helm-repositoryer (en index.yaml og chart-arkiver) leveres fra en fast liste:

Legg til et repository med proxyens URL og en legitimasjon med read:package:

helm repo add prometheus-community https://frem.sh/_app/proxy/<org>/helm/prometheus-community \
  --username <user or robot name> --password-stdin <<< "$FREMFORGE_TOKEN"
helm search repo prometheus-community/prometheus
helm pull prometheus-community/prometheus --version 29.36.1
helm install my-prometheus prometheus-community/prometheus --version 29.36.1

Hver chart-URL i indeksen peker tilbake til frem.sh, så Helm sender legitimasjonen din med hver nedlasting av et chart, og --pass-credentials trengs ikke.

Dette gjør proxyen:

• index.yaml kontrolleres på nytt hos repositoryet høyst hvert 5. minutt, og den siste gode kopien leveres mens repositoryet er nede eller svarer med noe som ikke er en Helm-indeks. Proxyen returnerer den som JSON, som Helm leser som YAML.
• Charts må stemme med digest (sha256) som repositoryets indeks registrerer for den versjonen, før de leveres. En versjon der indeksoppføringen ikke har noen digest, eller der chartet ikke ligger på repositoryets egne verter (for eksempel en oci://-URL), utelates fra indeksen du får. Med skanning etter skadevare slått på skannes hvert chart mens det strømmes til deg.
• Provenance-filer (.prov) sendes videre uendret, så helm pull --verify og helm install --verify fungerer med den offentlige nøkkelen til den som publiserer chartet, for eksempel for cert-manager: helm pull jetstack/cert-manager --version v1.21.2 --verify --keyring cert-manager-keyring.gpg. En provenance-fil må navngi chartet med indeksens digest, ellers leveres den ikke. Av de fire repositoryene publiserer jetstack og prometheus-community provenance-filer; for et chart uten, feiler --verify med failed to fetch provenance (404).
• Avhengighetene til et chart løses opp av Helm fra repositoryene som Chart.yaml nevner. En helm dependency update når de repositoryene direkte, med mindre du også legger dem til gjennom proxyen.

Bitnamis klassiske repository står ikke på listen: de gjeldende chart-versjonene der er OCI-artefakter på Docker Hub. Pull dem gjennom containerstien, oci://frem.sh/<org>/dependency-proxy/docker.io/bitnamicharts/<chart>, som bruker organisasjonens egen Docker Hub-legitimasjon (over).

For pakkepolicyen heter et chart det samme som chart-navnet. Utgivelsestidspunktet er created-datoen i indeksen, og lisensen er annotasjonen artifacthub.io/license, hvis chartet har en.

Cargo (crates.io)

Proxyen er et sparse registry for crates.io. Den krever Cargo 1.74 eller nyere. Erstatt crates-io med den i .cargo/config.toml, i prosjektet ditt eller i ~/.cargo/config.toml for alle prosjekter:

[source.crates-io]
replace-with = "fremforge"

[registries.fremforge]
index = "sparse+https://frem.sh/_app/proxy/<org>/cargo/index/"
credential-provider = "cargo:token"

Cargo sender tokenet som hele Authorization-headeren, så gi det prefikset Bearer. Hold det utenfor filen, i miljøet:

export CARGO_REGISTRIES_FREMFORGE_TOKEN="Bearer $FREMFORGE_TOKEN"
cargo fetch
cargo build --locked

Med kildeerstatningen kommer hver crate fra crates.io gjennom proxyen, også cratene som en eksisterende Cargo.lock låser, og ingen crate hentes utenom den.

Dette gjør proxyen:

• config.json er proxyens egen. Den peker nedlastinger av crates tilbake til organisasjonens sti på frem.sh og forteller Cargo at registeret krever autentisering, så Cargo sender tokenet med hver forespørsel om indeks og nedlasting.
• Indeksfiler kommer fra index.crates.io. De kontrolleres på nytt høyst hvert 5. minutt, og den siste gode kopien leveres mens crates.io er nede. Hver fil er crates.ios egen, versjon for versjon. Tilbaketrukne (yanked) versjoner blir stående, merket som yanked: Cargo bruker fortsatt en som Cargo.lock låser, og velger ikke en slik ved en ny oppløsning.
• Crates (.crate) kommer fra static.crates.io og må stemme med cksum (sha256) i indeksoppføringen før de leveres. En versjon der indeksoppføringen ikke har noen sjekksum, utelates. Med skanning etter skadevare slått på skannes hver crate mens den strømmes til deg, også inne i arkivet. Cargo kontrollerer den samme sjekksummen igjen på sin side.
• Søk, publisering, yanking og eiere tilbys ikke: cargo search svarer 404, og cargo publish avvises med 405. Publiser dine egne crates til organisasjonens Cargo-register.

For pakkepolicyen heter en crate det samme som navnet crates.io publiserer den under, og utgivelses- tidspunktet er pubtime i indeksoppføringen. Indeksen har ingen lisens, så lisensregler gjelder ikke for crates. Sårbarheter og ondsinnede crates kommer fra OSVs crates.io-data: RustSec-varslene og MAL-*-postene.

Terraform- og OpenTofu-moduler

Proxyen leverer offentlige moduler fra modulregistrene og fra offentlige Git-repositoryer, slik at tofu init og terraform init henter dem fra fremforges buffer i stedet for fra internett. Den dekker:

• Registermoduler fra registry.opentofu.org og registry.terraform.io, for eksempel terraform-aws-modules/vpc/aws eller Azure Verified Modules (Azure/avm-*).
• Git-kilder på github.com og gitlab.com på en tag eller en commit, for eksempel git::https://github.com/<owner>/<repo>.git?ref=v1.2.3 eller github.com/<owner>/<repo>?ref=v1.2.3.

En branch avvises: en bufret modul må forbli den samme, så angi en tag eller en commit. Private repositoryer, andre verter og SSH-kilder leveres ikke.

IaC-sjekken leser moduler gjennom denne bufferen for alle organisasjoner, også en der avhengighetsproxyen er slått av. Modulbuffernøkkelen, som din egen CI trenger, kan foreløpig bare opprettes i fremforges interne organisasjoner: for alle andre organisasjoner vises ikke seksjonen i konsollen, og API-et svarer 404.

Modulbuffernøkkelen

OpenTofu og Terraform når bufferen gjennom organisasjonens modulbuffernøkkel, som står i URL-en. En eier av organisasjonen oppretter den under Bygg og utrulling › Avhengighetsproxy › Terraform- og OpenTofu-moduler. Nøkkelen vises én gang, som en konfigurasjon klar til å lime inn for OpenTofu og én for Terraform. Etterpå viser siden bare de første tegnene, dagen den sist ble brukt, og en Roter-knapp. Etter en rotasjon virker den forrige nøkkelen i 24 timer, slik at pipelines som kjører, blir ferdige; deretter trenger hver CI-konfigurasjon den nye. Opprettelse og rotasjon av en nøkkel registreres i revisjonsloggen og når SIEM-en din som andre revisjonshendelser.

Nøkkelen kan også opprettes og roteres via API-et, med et token som har policy:write: GET /orgs/{org}/dependency-proxy/module-key viser prefikset og datoene (aldri nøkkelen), og POST /orgs/{org}/dependency-proxy/module-key med {"expect": "<current prefix>"} (eller "" når det ikke finnes noen) svarer med den nye nøkkelen én gang. Hvis en annen nøkkel har blitt gjeldende i mellomtiden, er svaret 409 module-key-stale, og ingenting endres.

Nøkkelen gir tilgang til å lese offentlige moduler som organisasjonen din, og ingenting annet. Behandle den som et passord: oppbevar den i CI-secrets, ikke i et repository.

Registermoduler: ingen endring i kildene dine

Pek OpenTofus register mot bufferen med en CLI-konfigurasjonsfil (~/.tofurc, eller filen TF_CLI_CONFIG_FILE angir). Linjene source og version forblir som de er:

host "registry.opentofu.org" {
  services = {
    "modules.v1"   = "https://frem.sh/_app/proxy/<org>/terraform/k/<module cache key>/registry/registry.opentofu.org/v1/modules/"
    "providers.v1" = "https://registry.opentofu.org/v1/providers/"
  }
}

• Behold begge linjene. host-blokken erstatter alt OpenTofu vet om registeret. Uten providers.v1 feiler hver installasjon av en provider med «does not offer a OpenTofu provider registry».
• Ikke legg til en credentials-blokk. OpenTofu og Terraform knytter legitimasjon til registerets vertsnavn, så et token i en slik blokk ville også blitt sendt til det offentlige registeret: med hver forespørsel om en provider, og med hver forespørsel på en maskin der host-blokken mangler. Modulbuffernøkkelen trenger ingen credentials-blokk.
• Terraform: skriv registry.terraform.io i stedet for registry.opentofu.org på alle tre stedene. Vi har verifisert denne konfigurasjonen på OpenTofu 1.13.1, med en nøkkel og med en feil nøkkel (403 Forbidden). Terraform dokumenterer den samme oppførselen for vert og legitimasjon; vi har ikke målt den.

For å kontrollere at bufferen brukes, kjører du TF_LOG=debug tofu init og ser etter linjer med GET https://frem.sh/_app/proxy/<org>/terraform/... for modulene dine.

Git-kilder

Angi proxyens arkiv for taggen eller commiten som en HTTPS-kilde. //* velger modulroten i arkivet, og en underkatalog følger etter:

module "network" {
  source = "https://frem.sh/_app/proxy/<org>/terraform/k/<module cache key>/git/github.com/<owner>/<repo>/v1.2.3.tar.gz//*/modules/network"
}

Ingen legitimasjon trengs utover modulbuffernøkkelen i URL-en.

Dette gjør proxyen

• En versjon låses ved første henting. Proxyen løser opp taggen til en commit fra repositoryets egen liste over Git-refs (det git ls-remote leser), henter arkivet for den commiten og registrerer commiten og arkivets SHA-256. Hver senere forespørsel, fra hvilken som helst organisasjon, får nøyaktig de bytene. En versjon av en registermodul låses til commiten taggen pekte på.
• En flyttet tag endrer ikke modulen din. Proxyen kontrollerer låste tagger på nytt høyst hver 6. time. Hvis en tag nå peker på en annen commit, fortsetter proxyen å levere den låste og registrerer at upstream-taggen er flyttet. Bare en operatør i fremforge kan låse en modul på nytt.
• Hva dette beskytter mot, og hva det ikke beskytter mot. Registre og Git-verter publiserer ingen sjekksum for modularkiver, så den første hentingen er klarert. Ingenting som endres upstream etter det, når deg: en tag som er pekt om, eller et arkiv som er generert på nytt, leveres ikke. En versjon som var ondsinnet da den først ble publisert, leveres slik den var.
• Arkiver kontrolleres før de leveres. Et arkiv som er større enn 50 MiB, som pakkes ut til mer enn 512 MiB eller 20 000 oppføringer, eller som inneholder en absolutt sti, en ..-sti, en enhetsfil eller en lenke som peker ut av arkivet, avvises, og ingenting lagres.
• Skanning etter skadevare gjelder for modularkiver som for andre filer når organisasjonen har den slått på. OSV har ikke noe Terraform-økosystem, så ingen liste over kjente ondsinnede pakker gjelder for moduler, og pakke- policyens regler for lisens og utgivelsesalder brukes ikke på dem.
• Delt, men logget per organisasjon. En offentlig modul lagres én gang for alle. Hver organisasjons hentinger registreres i dens egen tilgangslogg, med aktøren module-cache-key. Selve modulbuffernøkkelen skrives aldri til en logg.

Pakkepolicy og ondsinnede pakker

Organisasjonens pakkepolicy vurderes for npm-, PyPI-, RPM-, Maven-, NuGet-, Go- og Cargo-pakker og Helm-charts som hentes gjennom proxyen, med de samme reglene som for pakker i registeret ditt:

• Lister for tillatte, blokkerte og advarte lisenser, brukt på lisensen versjonen oppgir.
• Sårbarheter på eller over terskelen din for alvorlighetsgrad eller CVSS, fra OSV-databasen.
• Blokkerings- og tillatelseslister etter pakkenavn og versjonsområde.
• Minste utgivelsesalder, fra publiseringstidspunktet hos upstream.
• Ondsinnede pakker (OSV-varsler av typen MAL-*) sjekkes alltid, uansett hva policyen sier.

For RPM-pakker er versjonen [epoch:]version-release, lisensen er pakkens License-felt, og utgivelsesalderen er når pakken kom inn i repositoryet. OSV har ingen data om ondsinnede pakker eller sårbarheter for RPM-pakker, så de to sjekkene gjelder ikke for RPM-er i proxyen. Sårbarheter i RPM-pakker blir funnet når imagene som bygges av dem, skannes. Det samme gjelder for Helm-charts: OSV har ingen data for dem, så lisens, blokkeringslister og utgivelsesalder gjelder, og imagene et chart ruller ut, skannes der de pulles. Når avvisning er slått på, blir en blokkert chart-versjon stående i Helm-indeksen, og nedlastingen avvises med 403.

Avvisning er slått på siden 2026-10-11. En policy i modusen enforce fjerner en blokkert versjon fra npm-packumentet eller PyPI-indeksen, slik at resolveren din velger en tillatt versjon, og en direkte nedlasting av den avvises med 403 som navngir regelen. En policy i modusen shadow, som er standard, leverer fortsatt pakken og registrerer pullen i tilgangsloggen som would_block med regelen som slo til. Ondsinnede pakker avvises uansett hvilken modus policyen har, også Shadow og Off, og utelates fra pakkemetadataene proxyen leverer.

Når proxyen ikke kan få et policysvar fra fremforge (etter noen sekunder med nye forsøk, og uten et nylig svar for den samme pakken å falle tilbake på), avviser den nedlastingen med 503 i stedet for å levere en versjon den ikke kunne sjekke for skadevare. Et nytt forsøk senere lykkes når svaret er tilbake.

Varseldataene oppdateres fra fremforges OSV-speil flere ganger om dagen, og en policyendring gjelder fra neste pull. Ingenting trenger å skannes på nytt.

Dette håndheves i dag

Bufrede imager skannes også for sårbarheter og lekkede secrets, som imagene du pusher; se Skanning av imager.

Kjent utnyttede sårbarheter

Siden 2026-10-13 sjekker fremforge hver pakkeversjon som går gjennom proxyen, mot sårbarhetene som er kjent å bli utnyttet i praksis: ENISAs EU Vulnerability Database (EUVD) først, med CISAs Known Exploited Vulnerabilities-katalog i tillegg. En versjon teller bare når en slik sårbarhet rammer den og det finnes en rettet versjon, slik at det alltid finnes en versjon å gå over til. Dette er regelen fremforge allerede bruker på sine egne runner-imager.

Siden 2026-10-31 avvises en slik versjon. En nedlasting svarer 403 med en melding som nevner CVE-ene og ber deg oppgradere, og svaret har x-fremforge-proxy-policy: blocked;package_policy:known_exploited. Versjonen utelates også fra pakkemetadataene proxyen leverer, så et versjonsintervall velger en annen versjon i intervallet; bare en låsefil eller en byggefil som låser den berørte versjonen, feiler. Avvisningen registreres i tilgangsloggen din som enhver annen policyavvisning.

Dette er en plattformregel, som for ondsinnede pakker: den gjelder uansett policyens modus, og policyens unntak opphever den ikke. Organisasjonens egen bot for oppdatering av avhengigheter ser fortsatt disse versjonene i metadataene, så den kan foreslå oppgraderingen. fremforges egne skannere for pull requests leser dem også fortsatt, så en kjent utnyttet avhengighet fortsatt vises som et funn i stedet for å forsvinne fra skanningen.

Hvis et bygg feiler på den, bytt til den rettede versjonen: en pull request med en sikkerhetsretting er kanskje allerede åpen. Målt fra 2026-10-13 til 2026-10-31, før omleggingen, lastet ingen kundeorganisasjon ned en slik versjon.

Den samme kilden lar allerede en versjon som retter en kjent utnyttet sårbarhet, hoppe over policyens minste utgivelsesalder.

Lagring, tak og fakturering

Bufrede filer teller med full størrelse mot organisasjonens pakkelagring, som om de lå i ditt eget register. Et containerlag eller en npm- eller PyPI-fil som flere organisasjoner puller, lagres én gang, men teller med i hver organisasjons forbruk. RPM-innhold lagres per organisasjon (se RPM).

• Betalte planer: bufrede filer deler én pakkelagringspott med dine egne pakker. Med overforbruk slått av kan proxyen bruke det dine egne pakker lar være igjen av potten. Når ingenting er igjen, avvises nye hentinger med 403 (dependency proxy storage cap reached), og det som allerede er bufret, leveres fortsatt. Med overforbruk slått på finnes det ikke noe tak for proxyen, og lagring utover potten faktureres etter satsen for overforbruk av pakkelagring.
• Prøveperioder: en fast grense på 5 GB bufrede filer.

Siden Dependency proxy viser forbruket og taket ditt. Tallet for dine egne pakker som taket beregnes ut fra, oppdateres én gang i døgnet.

Oppbevaring

En bufret fil som organisasjonen din ikke har pullet på retention_days (standard 90, fra 7 til 365), fjernes fra bufferen din sammen med taggene som peker på den, og slutter å telle mot lagringen din. Kontrollen kjøres hver time. Når ingen organisasjon lenger viser til en fil, slettes den fra fremforges lager 24 timer senere. Pulles den igjen, hentes den fra upstream.

Pakkeversjoner som fortsatt er i bruk, beholdes. En pakkefil (npm, PyPI, Maven, NuGet, Go, Cargo, Helm eller RPM) fjernes ikke, uansett hvor lenge siden den sist ble pullet, så lenge den samme pakkeversjonen er en gjeldende komponent i organisasjonens komponentoversikt: i den gjeldende SBOM-en for et repositorys standardbranch, den siste utgivelsen, et gjeldende image, en aktiv registerpakke eller en opplastet SBOM. En avhengighet som er låst i en låsefil, men bare bygges to ganger i året, blir derfor værende i bufferen. Den teller fortsatt mot lagringen din. Når versjonen forsvinner fra alle gjeldende SBOM-er, gjelder den vanlige regelen igjen ved neste kontroll hver time.

Base-imager som de gjeldende byggene dine bruker, beholdes. Et bufret containerimage fjernes ikke, uansett hvor lenge siden det sist ble pullet, så lenge et av organisasjonens gjeldende imager er bygget på det: hvert lag i det bufrede imaget er også et lag i et image som fortsatt er publisert under en tag i organisasjonens register. Imagets manifest, konfigurasjon og alle lag beholdes sammen, slik at en pull av det fortsetter å virke, og det samme gjelder en indeks for flere plattformer der du bygger på plattformimaget. Et image som bare deler ett lag med byggene dine (for eksempel et annet image på samme distribusjon), beholdes ikke etter denne regelen. Det teller fortsatt mot lagringen din. Når ingen gjeldende imager lenger er bygget på det, gjelder den vanlige regelen igjen. Alle andre bufrede imager følger regelen om siste pull. To tilfeller gjenkjennes ikke og følger regelen om siste pull: et base-image som bare brukes for en annen plattform enn linux/amd64, og et bygg som komprimerer lagene i base-imaget på nytt i stedet for å gjenbruke dem.

Brudd hos upstream

Når et upstream-register er nede, tregt eller avviser forespørsler, fortsetter byggene å virke for alt organisasjonen din har pullet før:

• Filer du har pullet før (image-lag, .tgz, wheels, .jar, .nupkg, Go .zip og .mod, Helm-charts, crates) leveres fra fremforges lager. Leveringen venter aldri på upstream.
• Indekser og tagger (image-tagger, npm-packumenter, PyPI-indekser, RPM repomd.xml, Maven maven-metadata.xml, NuGet-versjonslister og -registreringer, Go @v/list og @latest, Helm index.yaml, Cargo-indeksfiler) besvares fra den siste gode kopien. Svaret har da X-Fremforge-Proxy: stale, så en ny utgivelse som publiseres under bruddet, er ikke synlig før upstream er tilbake.
• Image-tagger som en annen organisasjon har bufret, leveres også fra den siste gode kopien når organisasjonen din aldri har pullet den taggen: bare for offentlige imager som er pullet uten legitimasjon, og bare fra fremforges delte lager, aldri fra innhold en annen organisasjon har hentet med sin egen registerlegitimasjon. Docker Hub-imager hentes alltid med organisasjonens egen legitimasjon og deles ikke på denne måten.
• Alt som aldri har vært pullet før, svarer 502, fordi det ikke finnes noe å levere.

Hvis fremforges egen tjeneste for innlogging eller autorisasjon er utilgjengelig en kort stund, leveres forespørsler som ble tillatt de siste 15 minuttene, fortsatt fra bufferen (bare lesing). Et tilbakekalt token eller et fjernet medlemskap trer likevel i kraft så snart fremforge kan sjekke det.

Hva som overlever et brudd, begrenses av oppbevaringen. En fil organisasjonen din ikke har pullet på retention_days (standard 90), fjernes. Etter det må den hentes fra upstream igjen, noe som ikke er mulig mens upstream er nede. Pakkeversjoner i komponentoversikten din, og base-imagene de gjeldende imagene dine er bygget på, beholdes uansett (se Oppbevaring). For alt annet du trenger skal overleve et langt brudd, puller du det minst én gang innenfor oppbevaringsperioden, eller du øker retention_days.

Tilgangslogg

Hver pull gjennom proxyen vises i organisasjonens tilgangslogg for registeret med opprinnelsen proxy, unntatt to typer rutinemessig CI-trafikk: tillatte lesinger av metadata fra en CI-jobb (pakkeindekser og versjonslister) lagres ikke siden 2026-10-12, og nedlastinger fra en CI-jobb som proxyen leverer fra bufferen, telles i pull-tellingen per døgn, versjon, repository og kjøring siden 2026-10-13. Nedlastinger fra en CI-jobb som hentes fra upstream-registeret, avvisningene og feilene er fortsatt hendelser. Loggen registrerer pakken, versjonen og filen, hvem som pullet den (en bruker, eller for CI jobbens repository), utfallet og eventuelle policybeslutninger. En pull gjennom frem.sh som leveres fra bufferen, leveres av proxyen (200); en CI-jobbs pull er en videresending til objektlageret (307), unntatt Maven-filer på opptil 1 MiB. I begge tilfeller registreres størrelsen. En HEAD-forespørsel gjennom frem.sh registreres som GET, fordi CDN-et videresender HEAD-forespørsler til fremforge som GET. Avhengighetsskanningens egne lesinger (over) går ikke gjennom CDN-et eller opplastingsproxyen, så de står ikke i tilgangsloggen; fremforge logger dem som antall per skanning.

Hva upstream ser

fremforge kontakter upstream-registeret du har valgt, på dine vegne. Upstream mottar fremforges IP-adresse og navnet på imaget eller pakken. For docker.io, Red Hat-registrene og ghcr.io eller quay.io når du har lagret legitimasjon for dem, mottar det også organisasjonens egen legitimasjon, så pullen teller mot kontoen din der. Det mottar ingenting om brukerne dine. De fleste av disse registrene drives av selskaper utenfor EU. Etter den første hentingen leveres pulls fra fremforges lager i EU uten at upstream kontaktes igjen, unntatt for å kontrollere tagger, npm- og PyPI-metadata, RPM repomd.xml, Maven maven-metadata.xml og NuGet-versjonslister og -registreringer, Go-versjonslister, Helm index.yaml-filer og Cargo-indeksfiler på nytt (høyst hvert 5. minutt). Gos sjekksumdatabase nås også gjennom proxyen, på vegne av go-kommandoen.

Feil