Afhængighedsproxy

Afhængighedsproxyen er en pull-through-cache for offentlige registre, som kører pr. organisation. Du peger docker, npm, pip, uv, dnf, Maven, NuGet, go, helm eller cargo på din organisations proxysti på frem.sh, og fremforge henter fra det offentlige register på dine vegne:

• Den første hentning af et image-lag eller en pakkefil hentes fra upstream og kontrolleres mod upstreams egen hash. Hvis din organisation slår malwarescanning til, bliver den også scannet med ClamAV, mens den streames til dig. En fil, der fejler en kontrol, bliver aldrig udleveret og aldrig gemt.
• Senere hentninger udleveres fra fremforges lager i EU til alle medlemmer af din organisation.
• Hvis upstream er nede, udleveres den seneste gode kopi. Tags, npm-packuments, PyPI-indekser, RPM repomd.xml, Maven maven-metadata.xml, NuGet-versionslister og -registreringer, Go-versionslister og @latest, Helm index.yaml-filer og Cargo-indeksfiler besvares fra den seneste gode kopi med svarheaderen X-Fremforge-Proxy: stale. Se Nedbrud hos upstream.
• Din organisations pakkepolitik og kontrollerne for ondsindede pakker evalueres for pakker og images, der hentes gennem proxyen, og hver hentning registreres i din adgangslog for registret. Siden 2026-10-11 afvises en kendt ondsindet pakke eller et kendt ondsindet image for alle organisationer, og en politik i tilstanden Håndhæv afviser det, der bryder den; se Hvad der håndhæves i dag.

Proxyen er skrivebeskyttet. Du kan ikke pushe til den.

Tilgængelighed og aktivering

Proxyen findes på alle planer og er slået til som standard for alle organisationer. En ejer af organisationen kan slå den fra eller ændre dens indstillinger under Byg og udrul › Afhængighedsproxy 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 organisation, der aldrig har gemt disse indstillinger, har standarden: proxyen slået til, og hostede runnere henter gennem den (se Hostede runnere). Når en ejer har gemt dem, beholder organisationen præcis det, der blev gemt.

Malwarescanning (malware_scan) er slået fra som standard. Når den er slået til, scannes hvert image-lag, hver pakkefil og hvert chart, din organisation henter gennem proxyen, med ClamAV, også når en anden organisation har cachet det først uden at scanne det: den kopi scannes én gang, første gang en organisation, der scanner, bruger den, og resultatet gælder derefter for alle. Pakkefiler og charts scannes, før de udleveres; for image-lag, se Container-images. Kendte ondsindede pakker (OSV MAL-*-advisories) matches for alle organisationer, uanset hvad denne indstilling siger. Samme side og endpoint sætter block_until_scanned for container-images, som kræver, at malwarescanning er slået til (se Container-images), og retention_days (7 til 365, standard 90; se Opbevaring). Et GET på endpointet viser, om proxyen er slået til, dit forbrug og din grænse.

Godkendelse

Brug de samme legitimationsoplysninger som til pakkeregistret:

• Personer: et personligt adgangstoken med read:package (eller det kortlivede token, som fremforge auth giver dine værktøjer). Du skal være medlem af organisationen.
• CI: Forgejo Actions-jobbets token. Et jobtoken henter kun gennem sit eget repositorys organisation; alle andre organisationers proxy afviser det. Jobs fra pull requests fra forks må hente, men aldrig gennem en upstream, der bruger din organisations egne legitimationsoplysninger.
• Ekstern CI, build-værter og pull secrets: en registry-robot med læseadgang. Dens token er en read:package-legitimation som enhver anden.
• fremforges scanning af afhængigheder: reachability-analysen læser npm-tarballs, PyPI-wheels og Maven-JAR’er gennem din organisations proxy, på en intern rute, som kun scanningstjenesten kan nå. Licenskontrollen, kontrollen af udgivelsesalder og Go-modulgrafen læser registermetadata (npm, PyPI, Go, Maven Central, RubyGems og Packagist) på samme måde. Den er skrivebeskyttet, kan ikke bruges uden for fremforge og får din pakkepolitik, cache og lagergrænse som enhver anden hentning.

Hostede runnere

Som standard installerer jobs på runnere hostet af fremforge gennem din organisations proxy (runner_pull_through, slået til som standard). Ved starten af hvert job peger runneren npm, pip og uv på proxyen, og desuden Go, Maven, NuGet og Trivys sårbarhedsdatabase for de økosystemer, der står i runner_pull_through_ecosystems (alle fire som standard). Jobbet godkender sig med sit eget jobtoken, så hver installation passerer din pakkepolitik og dine malwarekontroller og står i din adgangslog med jobbets repository. Hvis proxyen ikke kan nås, når jobbet starter, installerer jobbet i stedet fra de offentlige registre gennem fremforges egress-proxy, og reserveløsningen logges. Sæt runner_pull_through til false for at slå det fra. Se også Pakkecaches.

Container-images. For de samme jobs henter jobbets Docker-daemon også container-images gennem din organisations proxy: docker pull, docker run, en Dockerfiles FROM samt de job- og services:-containere, runneren starter. Intet i workflowet ændres; image-navnene forbliver, som de er (ghcr.io/..., quay.io/...), og hver hentning caches for din organisation og registreres i din adgangslog.

• For alle organisationer: ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws og registry.access.redhat.com.
• Kun med din organisations egne legitimationsoplysninger: docker.io, registry.redhat.io og registry.connect.redhat.com går først gennem proxyen, når en ejer har tilføjet din organisations legitimationsoplysninger til det register under Upstream-legitimationsoplysninger. Jobs fra pull requests fra forks bruger dem aldrig, så deres hentninger fra disse registre går direkte til registret. Uden legitimationsoplysninger er hentninger fra Docker Hub anonyme og underlagt Docker Hubs hastighedsgrænser.
• Reserveløsning: proxyen kontrolleres ved starten af hvert job. Hvis den ikke kan nås, henter jobbet alle images direkte fra registret som før, og reserveløsningen logges. En enkelt hentning, som proxyen ikke kan levere, falder også igennem til registret.
• En cache, ikke en spærring: for images på denne vej falder en hentning, som din pakkepolitik eller malwarekontrollen afviser, også igennem til registret. Hvor en afvisning skal stoppe hentningen, så hent fra frem.sh/<org>/dependency-proxy/<registry>/<image> eksplicit (nedenfor).
• Ikke dækket: en docker buildx-builder, der bruger driveren docker-container, kører sin egen BuildKit og henter direkte. Standarddriveren docker går gennem proxyen.

Container-images

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

De upstreams, du kan hente fra:

Alle andre værter afvises: proxyen henter aldrig en vilkårlig URL.

Proxyen viser ikke et images tags. Hosted Renovate foreslår stadig opdateringer til et image, du refererer til gennem denne sti, for eksempel en Dockerfiles FROM frem.sh/<org>/dependency-proxy/docker.io/library/python:3.14-slim. Den slår nye tags og digests op i upstream-registret og skriver dem ind i din reference, som beholder proxystien. Dine builds henter fortsat gennem proxyen, så spærringerne for hentning nedenfor gælder stadig.

Helm-charts, der ligger som OCI-artefakter hos disse upstreams, kommer gennem samme sti (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.

Et tag kontrolleres igen hos upstream højst én gang i minuttet med en HEAD-forespørgsel, som Docker Hub ikke tæller med i sin grænse for hentninger. Image-lag passerer de samme spærringer for hentning som images, der pushes til dit register: med malwarescanning slået til afvises inficerede eller uscannelige lag, og det samme gør images over din CVE-tærskel, hvis du har sat block_pull. Ondsindede pakker inde i et image er beskrevet nedenfor. Som standard udleveres et image, mens dets lag scannes. Med block_until_scanned svarer den første hentning af et endnu ikke scannet image, eller af et lag efter digest, 503 med Retry-After, indtil scanningen er færdig, som regel inden for sekunder. Et lag, som en scanning har fundet inficeret, afvises for alle organisationer.

Mens én forespørgsel henter og scanner et lag, venter andre hentninger af det samme lag på den. Tager det mere end omkring fire minutter, får de 503 med Retry-After: 30 (this layer is still being fetched and malware-scanned by another request), og et nyt forsøg besvares, når laget er gemt. En scanning, der løber tør for tid, er ikke en dom: laget holdes tilbage som et uscanneligt lag, men der registreres intet resultat. Det sættes i kø hos fremforges baggrundsscanner af lag, som har et længere tidsbudget, og en senere hentning udleveres, når den scanning er bestået.

En pakkefil, hvis scanning løber tør for tid (npm, PyPI, RPM, Maven, NuGet, Go, Cargo eller et Helm-chart), behandles på samme måde: den anmodning afvises, der registreres intet resultat, og filen sættes i kø til den samme baggrundsscanner. En senere anmodning leveres, når den scanning er bestået, eller afvises, hvis den finder filen inficeret. En RPM forbliver din organisations egen, mens den venter: den gemmes og scannes kun i din organisations eget område, og en anden organisation, der henter den samme RPM, henter og scanner sin egen kopi.

Størrelsesgrænser. Proxyen udleverer intet lag og ingen fil over 10 GiB (403). ClamAV læser højst 4 GiB af én fil, så med malwarescanning slået til kan et større lag eller en større fil ikke scannes fuldt og holdes tilbage, undtagen et modellag i safetensors- eller GGUF-format, der består sin formatkontrol (se Scanning af modeller).

Ondsindede pakker inde i cachede images

Sprogpakkerne inde i hvert image, din organisation cacher (npm-, PyPI-, Maven-, Go-, crates-, RubyGems-, NuGet-, Packagist-, Pub- og Hex-pakker), matches mod OSV’s advisories for ondsindede pakker (MAL-*), den samme kontrol, som kører på de images, du pusher:

• efter at imaget er cachet første gang, som regel inden for den næste scanningscyklus (omkring 15 minutter), og
• igen hver dag, så en advisory, der udgives efter din hentning af imaget, stadig bliver fundet.

Et match er et kritisk fund under Sikkerhed › Fund › Afhængigheder › Malware, vist som et image med navnet <org>/dependency-proxy/<upstream>/<repository> og det digest, der indeholder det, og det sendes til dem, der modtager dine sikkerhedsadvarsler. Afvisning af fundet fungerer som for alle malwarefund, med en begrundelse og en valgfri slutdato. Fundet lukker af sig selv, når din organisation ikke længere cacher det image, for eksempel efter at opbevaringsreglen har fjernet det.

En hentning af et image med et åbent fund, der ikke er afvist, afvises med 403 DENIED, som for pushede images, og logges i din adgangslog som blocked med årsagen image_malware. Afvist siden 2026-10-11; før da blev en sådan hentning udleveret og registreret som would_block.

Upstream-legitimationsoplysninger

Docker Hub (docker.io) og Red Hats registre (registry.redhat.io og registry.connect.redhat.com, Red Hats certificerede partner-images) hentes kun gennem afhængighedsproxyen med din organisations egen konto. For GitHub (ghcr.io) og Quay (quay.io) er legitimationsoplysninger valgfrie: uden dem hentes der anonymt, hvilket giver adgang til offentlige images; tilføj dem for at hente dine private images. En ejer af organisationen tilføjer legitimationsoplysningerne under Byg og udrul › Afhængighedsproxy › Upstream-legitimationsoplysninger eller med API’et på /_app/api/v1/orgs/<org>/dependency-proxy/upstreams. Accepterede former:

• Docker Hub: dit brugernavn plus et personligt adgangstoken, eller et organisationsadgangstoken med Docker-organisationens navn som brugernavn.
• Red Hat: en servicekonto til registret (et brugernavn som 1234567|ci plus dens token) eller dens OpenShift-pull secret. Tilføj den én gang pr. Red Hat-register, du henter fra; hvert register beholder kun sin egen post fra pull secretet.
• GitHub (ghcr.io): dit GitHub-brugernavn plus et personligt adgangstoken (classic) med read:packages.
• Quay (quay.io): en robotkonto (organisation+robot) plus dens token, eller quay.io-posten fra et Red Hat-pull secret.

Red Hats registre med dine legitimationsoplysninger samt private ghcr.io- og quay.io-images er understøttet, men endnu ikke verificeret hele vejen igennem: fremforge har testet dem mod registrenes token-flow, men har ingen konto at hente med.

Når legitimationsoplysninger til ghcr.io eller quay.io er gemt, bruger hver hentning fra det register dem, også for offentlige images, og resultatet caches kun for din organisation. Jobs fra pull requests fra forks bruger dem aldrig: de henter fra de to registre anonymt og får derfor kun offentlige images.

Secretet gemmes krypteret og bruges kun af afhængighedsproxyen til din egen organisations hentninger. Det vises aldrig igen; du ser et fingeraftryk i stedet. Test forbindelsen kontrollerer det og viser for Docker Hub, hvor mange hentninger der er tilbage i dit nuværende grænsevindue.

Images, der er hentet med dine legitimationsoplysninger, caches kun for din organisation og udleveres aldrig til en anden organisation. Jobs fra pull requests fra forks kan ikke hente gennem et register, der kræver dine legitimationsoplysninger. Hvis legitimationsoplysningerne udløber, udleveres allerede cachede images fortsat, og status viser Afvist af registret. Uden legitimationsoplysninger afvises en hentning fra Docker Hub med en meddelelse, der siger det.

Kubernetes og OpenShift

Peg et mirror på 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 til digests):

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

Clusterets pull secret skal have et frem.sh-token med read:package.

npm

.npmrc i dit projekt eller din hjemmemappe:

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

Brug derefter npm, pnpm eller yarn som normalt. Pakker kommer fra registry.npmjs.org, inklusive scoped pakker. Hver tarball skal matche den integrity (sha512), som npm-registret udgiver for den, før den udleveres.

npm audit og pnpm audit virker mod proxyen. De besvares fra fremforges egen kopi af OSV’s advisory-database, så din afhængighedsliste ikke sendes til nogen tredjeparts advisory-tjeneste. Understøttede klienter og svarformatet er beskrevet under npm audit og pnpm audit gennem afhængighedsproxyen.

For at kombinere proxyen med pakker, din organisation udgiver i sit eget register, så send dit scope til registret og alt andet 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 legitimationsoplysningerne i en netrc-fil eller en keyring frem for i URL’en. Indekset udleveres i begge de formater, installationsværktøjer bruger (PEP 503 HTML og PEP 691 JSON), med hver fils sha256, requires-python, yank-status og PEP 658-metadata. Hver fil skal matche den sha256, som PyPI angiver for den, før den udleveres.

Brug proxyen som dit eneste indeks. Tilføj den ikke med --extra-index-url (eller PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL) ved siden af et andet indeks, eller et andet indeks ved siden af den: blandede indekser er det, der gør dependency confusion-angreb mulige, fordi installationsværktøjet tager et navn fra det indeks, der tilbyder det. For at installere pakker, din organisation udgiver i sit eget register, så kør en separat installation med det register som eneste indeks og --no-deps, eller fastlås med uv hver af dem til det ved 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 repositories med Universal Base Image (UBI 8, 9 og 10: BaseOS, AppStream og CodeReady Builder til alle arkitekturer, Red Hat udgiver), under content/public/ubi/. De kræver ingen Red Hat-konto. En .repo-fil til 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-godkendelse. Brug en registry-robot til build-værter og image-builds, og gør filen læsbar kun for root (chmod 600), fordi den indeholder tokenet. I et container-build skal du slå imagets egne repositories fra under installationen (dnf --disablerepo='*' --enablerepo='*-fremforge' install …), så intet hentes uden om proxyen.

Hvad proxyen gør:

• repodata/repomd.xml kontrolleres igen hos upstream højst hvert 5. minut og udleveres præcis, som upstream udgav den. En ny repomd.xml accepteres først, når den primary.xml, den nævner, er hentet og matcher den sha256 og størrelse, repomd.xml angiver for den. Indtil da, og mens upstream er nede, udleveres den forrige.
• Repository-metadatafiler (primary, filelists, other, updateinfo, modules, comps og sqlite-varianterne) skal matche sha256 og størrelse i repomd.xml.
• Pakker skal matche sha256 og størrelse i primary.xml. Med malwarescanning slået til scannes hver pakke også inde i sin komprimerede payload, ikke kun som fil, og dens installationsscripts scannes også. En pakke, som scanneren ikke kan åbne, afvises da i stedet for at blive udleveret uscannet.
• Pakkesignaturer kontrolleres af dnf selv (gpgcheck=1) mod Red Hats nøgle, præcis som uden proxyen. Proxyen ændrer aldrig en pakke eller repository-metadata.
• RPM-indhold caches kun for din organisation. En anden organisation, der henter den samme pakke, henter og gemmer sin egen kopi. Det er for, at den samme kodesti senere kan udlevere Red Hat-indhold hentet med dit eget Red Hat-abonnement, som aldrig må nå en anden kunde.

Et repository, der bruger andre checksums end sha256, udleveres ikke. Proxy til cdn.redhat.com med dit Red Hat-entitlement-certifikat er planlagt og endnu ikke tilgængeligt.

Maven

Maven Central nås på

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

Gør den til mirror for alle repositories i ~/.m2/settings.xml (eller den settings.xml, dit build bruger), med legitimationsoplysningerne 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 brugernavn og adgangskode som HTTP Basic-godkendelse, når proxyen beder om dem. For at bruge proxyen sammen med pakker, din organisation udgiver i sit eget register, så skriv <mirrorOf>*,!fremforge</mirrorOf> og erklær dit register (https://frem.sh/api/packages/<org>/maven) som repository 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()
            }
        }
    }
}

Hvad proxyen gør:

• maven-metadata.xml kontrolleres igen hos Maven Central højst hvert 5. minut. En ny kopi accepteres kun, når den matcher Maven Centrals egen .sha1 af den. Indtil da, og mens Maven Central er nede, udleveres den forrige kopi. Dens .sha1, .md5, .sha256 og .sha512 beregnes ud fra den kopi, du får udleveret, så de altid matcher den.
• Artefakter (jars, POM’er, .module-filer og alle andre filer i en udgivelse) skal matche Maven Centrals .sha1 og, når Maven Central udgiver en, dens .sha256. En fil uden nogen af de to checksums hentes ikke. Med malwarescanning slået til scannes hver fil, mens den streames til dig. En jar åbnes også: en post, som scanneren ikke selv kan pakke ud (zstd), pakkes ud for den, og en jar med en post, som ingen af dem kan åbne (for eksempel LZMA), afvises i stedet for at blive udleveret uscannet.
• Last-Modified er det tidspunkt, hvor Maven Central udgav filen, også når den kommer fra cachen, så Renovates minimumsalder for udgivelser og andre værktøjer, der læser den, ser det reelle udgivelsestidspunkt. En fil, som Maven Central sendte uden en, får slet ingen Last-Modified, aldrig det tidspunkt, hvor fremforge cachede den. Et HEAD på en cachet fil svarer 200 med dens Content-Length og denne Last-Modified.
• Checksumfiler (.sha1, .sha256, …) og signaturer (.asc) for artefakter sendes uændret videre. Kontrollér signaturer med dit builds PGP-plugin, som du ville gøre uden proxyen.
• Snapshots udleveres ikke. Maven Central udgiver ingen, og et snapshot kan ændre sig under samme version. En -SNAPSHOT-forespørgsel besvares med 404, så dit build går videre til det repository, der har den.

I pakkepolitikken hedder en Maven-pakke groupId:artifactId. Dens udgivelsestidspunkt er, når Maven Central udgav filen, og dens licens er de <licenses>, dens POM erklærer. En licens, der arves fra en forældre-POM, slås ikke op og tæller derfor som ikke vurderet.

NuGet

Pakkekilden er proxyens serviceindeks:

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

nuget.config ved siden af din solution:

<?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 /> gør proxyen til den eneste kilde, så ingen pakke hentes uden om den. NuGet udfylder %FREMFORGE_TOKEN% fra miljøet, så tokenet ikke behøver at stå i filen. Brug derefter dotnet restore, dotnet add package <id> --version <version> eller nuget install som normalt.

Hvad proxyen gør:

• Serviceindekset viser kun ressourcer på frem.sh: pakkeindholdet (flat container) og pakkeregistreringen. Søgning leveres ikke, fordi restore og install ikke har brug for den. dotnet add package uden --version kræver søgning, så angiv versionen.
• Versionslister og registrering kontrolleres igen hos nuget.org højst hvert 5. minut, og den seneste gode kopi udleveres, mens nuget.org er nede.
• Pakker (.nupkg) skal matche den SHA-512 og størrelse, som nuget.orgs katalog registrerer for udgivelsen, før de udleveres. En udgivelse, hvis katalogpost ikke har nogen hash, hentes ikke. Med malwarescanning slået til scannes hver pakke, mens den streames til dig, både inde i pakken og som fil.
• Pakkesignaturer kontrolleres af NuGet-klienten selv, præcis som uden proxyen. Proxyen ændrer aldrig en pakke.

I pakkepolitikken hedder en NuGet-pakke sit id med små bogstaver. Dens udgivelsestidspunkt og licens er nuget.orgs published-dato og pakkens erklærede licensudtryk. En pakke, der erklærer sin licens som en fil eller en URL, tæller som ikke vurderet.

Go-moduler

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

Godkendelse kommer fra ~/.netrc (_netrc på Windows), som go-kommandoen læser for frem.sh. Gør filen læsbar kun for dig (chmod 600 ~/.netrc):

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

Brug GOPROXY=https://frem.sh/_app/proxy/<org>/go i stedet for at tilføje ,direct: med direct hentes et modul, som proxyen ikke udleverer, fra sit kilderepository uden om proxyen.

Hvad proxyen gør:

• @v/list og @latest kontrolleres igen hos proxy.golang.org højst hvert 5. minut, og den seneste gode kopi udleveres, mens den er nede.
• .mod og .zip skal matche de h1:-hashes, som Go-checksumdatabasen (sum.golang.org) har signeret for den modulversion. Proxyen verificerer databasens signatur med den samme nøgle, som er indbygget i go-kommandoen. En modul-zip pakkes ud og hashes på samme måde, som go-kommandoen hasher den, før den udleveres. Et modul, som checksumdatabasen ikke kender, udleveres ikke. Med malwarescanning slået til scannes hver zip, mens den streames til dig.
• Checksumdatabasen nås også gennem proxyen. go-kommandoen spørger proxyen, om den udleverer sum.golang.org, og henter derefter hvert opslag og hver tile gennem den. Så GOSUMDB forbliver slået til og udfører stadig sin egen fulde verifikation, inklusive de beviser, som proxyen ikke selv gentager, og din maskine har ikke brug for direkte adgang til sum.golang.org.
• Private moduler udleveres ikke: proxy.golang.org kan ikke hente dem, og checksumdatabasen kender dem ikke. Udelad dem med GOPRIVATE (eller GONOPROXY og GONOSUMDB), så henter go-kommandoen dem fra din egen Git-hosting som før.
• Moduler hostet på frem.sh spørges der aldrig Google om. En forespørgsel efter et modul under frem.sh (eller et underdomæne) afvises med 404, før proxyen kontakter nogen, fordi forespørgslen i sig selv ville fortælle proxy.golang.org og sum.golang.org modulets sti. Sæt frem.sh i GOPRIVATE, så go-kommandoen henter de moduler direkte fra frem.sh.

Hvad Google får at vide om offentlige moduler

Proxyen henter offentlige Go-moduler fra Googles modul-mirror (proxy.golang.org) og kontrollerer dem mod Googles checksumdatabase (sum.golang.org). Når et modul eller en version endnu ikke er cachet, modtager Google derfor:

• modulstien og versionen, der hentes (for eksempel github.com/gorilla/websocket@v1.5.0), og opslagene i checksumdatabasen for den;
• forespørgsler fra fremforges egress-adresser, ikke fra dine maskiner, uden din organisations navn, bruger, token eller repository.

Google modtager ikke din kode, din go.mod, navnene på dine repositories eller hvilken organisation der spurgte. Et modul, der allerede er cachet, udleveres uden at kontakte Google. Det samme gælder sikkerhedsscannerne: de læser offentlige Go-moduler gennem denne proxy og spørger aldrig efter et modul, der er privat efter reglerne ovenfor.

I pakkepolitikken hedder et Go-modul sin modulsti. Dets udgivelsestidspunkt er det tidspunkt, proxy.golang.org registrerer for versionen. Go-moduler erklærer ingen licens, som proxyen kan læse, så licensregler gælder ikke for dem.

Helm-charts

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

Tilføj et repository med proxyens URL og legitimationsoplysninger 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 indekset peger tilbage på frem.sh, så Helm sender dine legitimationsoplysninger med hver chart-download, og --pass-credentials er ikke nødvendig.

Hvad proxyen gør:

• index.yaml kontrolleres igen hos repositoryet højst hvert 5. minut, og den seneste gode kopi udleveres, mens repositoryet er nede eller svarer med noget, der ikke er et Helm-indeks. Proxyen returnerer det som JSON, som Helm læser som YAML.
• Charts skal matche det digest (sha256), som repositoryets indeks registrerer for den version, før de udleveres. En version, hvis indekspost ikke har noget digest, eller hvis chart ikke ligger på repositoryets egne værter (for eksempel en oci://-URL), udelades af det indeks, du får. Med malwarescanning slået til scannes hvert chart, mens det streames til dig.
• Provenance-filer (.prov) sendes uændret videre, så helm pull --verify og helm install --verify virker med chart-udgiverens offentlige nøgle, for eksempel for cert-manager: helm pull jetstack/cert-manager --version v1.21.2 --verify --keyring cert-manager-keyring.gpg. En provenance-fil skal nævne chartet med indeksets digest, ellers udleveres den ikke. Af de fire repositories udgiver jetstack og prometheus-community provenance-filer; for et chart uden en fejler --verify med failed to fetch provenance (404).
• Et charts afhængigheder opløses af Helm fra de repositories, dets Chart.yaml nævner. En helm dependency update går direkte til de repositories, medmindre du også tilføjer dem gennem proxyen.

Bitnamis klassiske repository er ikke på listen: dets aktuelle chart-versioner er OCI-artefakter på Docker Hub. Hent dem gennem container-stien, oci://frem.sh/<org>/dependency-proxy/docker.io/bitnamicharts/<chart>, som bruger din organisations egne Docker Hub-legitimationsoplysninger (ovenfor).

I pakkepolitikken hedder et chart sit chart-navn. Dets udgivelsestidspunkt er created-datoen i indekset, og dets licens er annotationen artifacthub.io/license, hvis chartet har en.

Cargo (crates.io)

Proxyen er et sparse registry for crates.io. Det kræver Cargo 1.74 eller nyere. Erstat crates-io med det i .cargo/config.toml, i dit projekt eller i ~/.cargo/config.toml for alle projekter:

[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å giv det præfikset Bearer. Hold det ude af 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 gennem proxyen, inklusive de crates, en eksisterende Cargo.lock fastlåser, og ingen crate hentes uden om den.

Hvad proxyen gør:

• config.json er proxyens egen. Den peger crate-downloads tilbage til din organisations sti på frem.sh og fortæller Cargo, at registret kræver godkendelse, så Cargo sender tokenet med hver indeks- og download-forespørgsel.
• Indeksfiler kommer fra index.crates.io. De kontrolleres igen højst hvert 5. minut, og den seneste gode kopi udleveres, mens crates.io er nede. Hver fil er crates.ios egen, version for version. Yankede versioner bliver stående, markeret som yanked: Cargo bruger stadig en, som din Cargo.lock fastlåser, men vælger ikke en ved en ny opløsning.
• Crates (.crate) kommer fra static.crates.io og skal matche den cksum (sha256), der står i deres indekspost, før de udleveres. En version, hvis indekspost ikke har nogen checksum, udelades. Med malwarescanning slået til scannes hver crate, mens den streames til dig, også inde i arkivet. Cargo kontrollerer den samme checksum igen på sin side.
• Søgning, udgivelse, yanking og ejere leveres ikke: cargo search svarer 404, og cargo publish afvises med 405. Udgiv dine egne crates i din organisations Cargo-register.

I pakkepolitikken hedder en crate sit navn, som crates.io udgiver det, og dens udgivelsestidspunkt er pubtime i dens indekspost. Indekset indeholder ingen licens, så licensregler gælder ikke for crates. Sårbarheder og ondsindede crates kommer fra OSV’s crates.io-data: RustSec-advisories og MAL-*-posterne.

Terraform- og OpenTofu-moduler

Proxyen udleverer offentlige moduler fra modulregistrene og fra offentlige Git-repositories, så tofu init og terraform init henter dem fra fremforges cache i stedet for fra internettet. Den dækker:

• 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 ved et 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 afvises: et cachet modul skal forblive det samme, så angiv et tag eller en commit. Private repositories, andre værter og SSH-kilder udleveres ikke.

IaC-kontrollen læser moduler gennem denne cache for alle organisationer, også en, hvis afhængighedsproxy er slået fra. Modul-cachenøglen, som din egen CI har brug for, kan indtil videre kun oprettes i fremforges interne organisationer: for alle andre organisationer vises sektionen i konsollen ikke, og API’et svarer 404.

Modul-cachenøglen

OpenTofu og Terraform når cachen gennem din organisations modul-cachenøgle, som står i URL’en. En ejer af organisationen opretter den under Byg og udrul › Afhængighedsproxy › Terraform- og OpenTofu-moduler. Nøglen vises én gang, som en konfiguration klar til at indsætte for OpenTofu og én for Terraform. Derefter viser siden kun dens første tegn, den dag, den sidst blev brugt, og en Rotér-knap. Efter en rotation virker den forrige nøgle fortsat i 24 timer, så kørende pipelines kan blive færdige; derefter skal alle CI-konfigurationer have den nye. Oprettelse og rotation af en nøgle registreres i revisionsloggen og når din SIEM som andre revisionshændelser.

Nøglen kan også oprettes og roteres gennem API’et med et token, der har policy:write: GET /orgs/{org}/dependency-proxy/module-key viser dens præfiks og datoer (aldrig nøglen), og POST /orgs/{org}/dependency-proxy/module-key med {"expect": "<current prefix>"} (eller "", når der ikke er nogen) returnerer den nye nøgle én gang. Hvis en anden nøgle er blevet den aktuelle i mellemtiden, er svaret 409 module-key-stale, og intet ændres.

Nøglen giver adgang til at læse offentlige moduler som din organisation og intet andet. Behandl den som en adgangskode: opbevar den i dine CI-secrets, ikke i et repository.

Registermoduler: ingen ændring af dine kilder

Peg OpenTofus register på cachen med en CLI-konfigurationsfil (~/.tofurc eller den fil, TF_CLI_CONFIG_FILE angiver). Dine source- og version-linjer forbliver, 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 linjer. host-blokken erstatter alt, hvad OpenTofu ved om registret. Uden providers.v1 fejler hver provider-installation med “does not offer a OpenTofu provider registry”.
• Tilføj ikke en credentials-blok. OpenTofu og Terraform matcher legitimationsoplysninger med registrets værtsnavn, så et token i en sådan blok også ville blive sendt til det offentlige register: med hver provider-forespørgsel og med hver forespørgsel på en maskine, hvor host-blokken mangler. Modul-cachenøglen kræver ingen credentials-blok.
• Terraform: skriv registry.terraform.io i stedet for registry.opentofu.org alle tre steder. Vi har verificeret denne konfiguration på OpenTofu 1.13.1, med en nøgle og med en forkert (403 Forbidden). Terraform dokumenterer den samme opførsel for værter og legitimationsoplysninger; den har vi ikke målt.

For at kontrollere, at cachen bruges, så kør TF_LOG=debug tofu init, og kig efter linjer med GET https://frem.sh/_app/proxy/<org>/terraform/... for dine moduler.

Git-kilder

Angiv proxyens arkiv for tagget eller committen som en HTTPS-kilde. //* vælger modulets rod i arkivet, og en undermappe følger efter:

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"
}

Der kræves ingen legitimationsoplysninger ud over modul-cachenøglen i URL’en.

Hvad proxyen gør

• En version fastlåses ved første hentning. Proxyen opløser tagget til en commit ud fra repositoryets egen liste over Git-refs (det, git ls-remote læser), henter den commits arkiv og registrerer committen og arkivets SHA-256. Hver senere forespørgsel, fra enhver organisation, får præcis de bytes. En version af et registermodul fastlåses til den commit, dens tag pegede på.
• Et flyttet tag ændrer ikke dit modul. Proxyen kontrollerer fastlåste tags igen højst hver 6. time. Hvis et tag nu peger på en anden commit, bliver proxyen ved med at udlevere den fastlåste og registrerer, at upstream-tagget er flyttet. Kun en operatør hos fremforge kan fastlåse et modul igen.
• Hvad det beskytter mod, og hvad ikke. Registre og Git-værter udgiver ingen checksum for modularkiver, så den første hentning stoles på. Intet, der ændres upstream derefter, når dig: et tag, der peges om, eller et arkiv, der genereres igen, udleveres ikke. En version, der var ondsindet, da den først blev udgivet, udleveres, som den var.
• Arkiver kontrolleres, før de udleveres. Et arkiv større end 50 MiB, som udpakket fylder mere end 512 MiB eller 20.000 poster, eller som indeholder en absolut sti, en ..-sti, en enhedsfil eller et link, der peger uden for arkivet, afvises, og intet gemmes.
• Malwarescanning gælder for modularkiver som for andre filer, når din organisation har slået den til. OSV har intet Terraform-økosystem, så ingen liste over kendte ondsindede pakker gælder for moduler, og pakkepolitikkens regler for licens og udgivelsesalder anvendes ikke på dem.
• Delt, logget pr. organisation. Et offentligt modul gemmes én gang for alle. Hver organisations hentninger registreres i dens egen adgangslog med aktøren module-cache-key. Selve modul-cachenøglen skrives aldrig til en log.

Pakkepolitik og ondsindede pakker

Din organisations pakkepolitik evalueres for npm-, PyPI-, RPM-, Maven-, NuGet-, Go- og Cargo-pakker og Helm-charts, der hentes gennem proxyen, med de samme regler som for pakker i dit register:

• Licens: lister over tilladte, afviste og advarede licenser, anvendt på versionens erklærede licens.
• Sårbarheder på eller over din tærskel for alvorlighed eller CVSS, fra OSV-databasen.
• Afvisnings- og tilladelseslister efter pakkenavn og versionsinterval.
• Minimumsalder for udgivelser, ud fra upstreams udgivelsestidspunkt.
• Ondsindede pakker (OSV MAL-*-advisories) kontrolleres altid, uanset hvad politikken siger.

For RPM-pakker er versionen [epoch:]version-release, licensen er pakkens License-felt, og udgivelsesalderen er, hvornår pakken kom ind i repositoryet. OSV har ingen data om ondsindede pakker eller sårbarheder for RPM-pakker, så de to kontroller gælder ikke for RPM’er i proxyen. Sårbarheder i RPM-pakker findes, når de images, der bygges af dem, scannes. Det samme gælder for Helm-charts: OSV har ingen data for dem, så licens, afvisningslister og udgivelsesalder gælder, og de images, et chart udruller, scannes, hvor de hentes. Når afvisning er slået til, bliver en blokeret chart-version stående i Helm-indekset, og downloaden af den afvises med 403.

Afvisning er slået til siden 2026-10-11. En politik i tilstanden Håndhæv fjerner en blokeret version fra npm-packumentet eller PyPI-indekset, så din resolver vælger en tilladt version, og en direkte download af den afvises med 403, der nævner reglen. En politik i tilstanden Skygge, som er standard, udleverer stadig pakken og registrerer hentningen i adgangsloggen som would_block med den regel, der matchede. Ondsindede pakker afvises uanset din politiks tilstand, også Skygge og Off, og udelades af de pakkemetadata, proxyen udleverer.

Mens proxyen ikke kan få et svar på politikken fra fremforge (efter nogle sekunders nye forsøg, og uden et nyligt svar for den samme pakke at falde tilbage på), afviser den downloaden med 503 i stedet for at udlevere en version, den ikke har kunnet kontrollere for malware. Et nyt forsøg senere lykkes, når svaret er tilbage.

Advisory-data opdateres fra fremforges OSV-mirror flere gange om dagen, og en ændring af politikken gælder for den næste hentning. Intet skal scannes igen.

Hvad der håndhæves i dag

Cachede images scannes også for sårbarheder og lækkede secrets som de images, du pusher; se Scanning af images.

Kendt udnyttede sårbarheder

Siden 2026-10-13 kontrollerer fremforge hver pakkeversion, der hentes gennem proxyen, mod de sårbarheder, der vides at blive udnyttet i praksis: ENISA’s EU Vulnerability Database (EUVD) først, med CISA’s katalog over Known Exploited Vulnerabilities lagt ovenpå. En version tæller kun, når en sådan sårbarhed rammer den, og der findes en rettet version, så der altid er en version at skifte til. Det er den regel, fremforge allerede anvender på sine egne runner-images.

Siden 2026-10-31 afvises en sådan version. En download svarer 403 med en besked, der nævner CVE’erne og beder dig opgradere, og svaret har x-fremforge-proxy-policy: blocked;package_policy:known_exploited. Versionen udelades også af de pakkemetadata, proxyen udleverer, så et versionsinterval vælger en anden version i intervallet; kun en lockfil eller en build-fil, der fastlåser den berørte version, fejler. Afvisningen registreres i din adgangslog som enhver anden politikafvisning.

Det er en platformsregel, ligesom ondsindede pakker: den gælder uanset din politiks tilstand, og din politiks undtagelser ophæver den ikke. Din organisations egen bot til opdatering af afhængigheder ser stadig disse versioner i metadataene, så den kan foreslå opgraderingen. fremforges egne scannere af pull requests læser dem også stadig, så en kendt udnyttet afhængighed fortsat vises som et fund i stedet for at forsvinde fra scanningen.

Hvis et build fejler på den, så skift til den rettede version: en pull request med en sikkerhedsrettelse er måske allerede åben. Målt fra 2026-10-13 til 2026-10-31, før skiftet, downloadede ingen kundeorganisation en sådan version.

Det samme feed lader allerede en version, der retter en kendt udnyttet sårbarhed, springe din politiks minimumsalder for udgivelser over.

Lager, grænser og fakturering

Cachede filer tæller med i din organisations pakkelager med deres fulde størrelse, som om de lå i dit eget register. Et container-lag eller en npm- eller PyPI-fil, som flere organisationer henter, gemmes én gang, men tæller med i hver organisations forbrug. RPM-indhold gemmes pr. organisation (se RPM).

• Betalte planer: cachede filer deler én lagerpulje til pakker med dine egne pakker. Med overforbrug slået fra må proxyen bruge det, dine egne pakker efterlader af puljen. Når der ikke er mere tilbage, afvises nye hentninger med 403 (dependency proxy storage cap reached), og det, der allerede er cachet, udleveres stadig. Med overforbrug slået til er der ingen grænse for proxyen, og lager ud over puljen faktureres til takten for overforbrug af pakkelager.
• Prøveperioder: fast 5 GB cachede filer.

Siden Afhængighedsproxy viser dit forbrug og din grænse. Tallet for dine egne pakker, som grænsen beregnes ud fra, opdateres én gang om dagen.

Opbevaring

En cachet fil, som din organisation ikke har hentet i retention_days (standard 90, fra 7 til 365), fjernes fra din cache sammen med de tags, der peger på den, og holder op med at tælle med i dit lager. Kontrollen kører hver time. Når ingen organisation længere refererer til en fil, slettes den fra fremforges lager 24 timer senere. Henter du den igen, hentes den fra upstream.

Pakkeversioner, der stadig er i brug, beholdes. En pakkefil (npm, PyPI, Maven, NuGet, Go, Cargo, Helm eller RPM) fjernes ikke, uanset hvor længe siden den sidst blev hentet, så længe den samme pakkeversion er en aktuel komponent i din organisations komponentbeholdning: i den aktuelle SBOM for et repositorys standardbranch, dens seneste release, et aktuelt image, en aktiv registerpakke eller en uploadet SBOM. En afhængighed, der er fastlåst i en lockfil, men kun bygges to gange om året, forbliver derfor cachet. Den tæller stadig med i dit lager. Når versionen forsvinder fra alle aktuelle SBOM’er, gælder den normale regel igen ved den næste kontrol hver time.

Base-images, som dine aktuelle builds bruger, beholdes. Et cachet container-image fjernes ikke, uanset hvor længe siden det sidst blev hentet, så længe et af din organisations aktuelle images er bygget på det: hvert lag i det cachede image er også et lag i et image, der stadig er udgivet under et tag i din organisations register. Imagets manifest, dets konfiguration og alle dets lag beholdes samlet, så en hentning af det fortsat virker, og det samme gælder et indeks til flere platforme, hvis platform-image du bygger på. Et image, der kun deler et lag med dine builds (for eksempel et andet image på den samme distribution), beholdes ikke efter denne regel. Det tæller stadig med i dit lager. Når intet aktuelt image længere er bygget på det, gælder den normale regel igen. Alle andre cachede images følger reglen om seneste hentning. To tilfælde genkendes ikke og følger reglen om seneste hentning: en base, der kun bruges til en anden platform end linux/amd64, og et build, der komprimerer base-imagets lag igen i stedet for at genbruge dem.

Nedbrud hos upstream

Når et upstream-register er nede, langsomt eller afviser, bliver builds ved med at virke for alt, din organisation har hentet før:

• Filer, du har hentet før (image-lag, .tgz, wheels, .jar, .nupkg, Go .zip og .mod, Helm-charts, crates), udleveres fra fremforges lager. Udleveringen venter aldrig på upstream.
• Indekser og tags (image-tags, npm-packuments, PyPI-indekser, RPM repomd.xml, Maven maven-metadata.xml, NuGet-versionslister og -registreringer, Go @v/list og @latest, Helm index.yaml, Cargo-indeksfiler) besvares fra den seneste gode kopi. Svaret har da X-Fremforge-Proxy: stale, så en ny udgivelse, der udkommer under nedbruddet, ikke er synlig, før upstream er tilbage.
• Image-tags, som en anden organisation har cachet, udleveres også fra den seneste gode kopi, når din organisation aldrig har hentet det tag: kun for offentlige images hentet uden legitimationsoplysninger, og kun fra fremforges delte lager, aldrig fra indhold, som en anden organisation har hentet med sine egne legitimationsoplysninger til registret. Docker Hub-images hentes altid med din organisations egne legitimationsoplysninger og deles ikke på denne måde.
• Alt, der aldrig er hentet før, svarer 502, fordi der ikke er noget at udlevere.

Hvis fremforges egen login- eller autorisationstjeneste kortvarigt er utilgængelig, bliver forespørgsler, der blev tilladt inden for de seneste 15 minutter, fortsat udleveret fra cachen (kun læsning). Et tilbagekaldt token eller et fjernet medlemskab får stadig virkning, så snart fremforge kan kontrollere det.

Hvad der overlever et nedbrud, er begrænset af opbevaring. En fil, som din organisation ikke har hentet i retention_days (standard 90), fjernes. Derefter skal den hentes fra upstream igen, hvilket ikke er muligt, mens upstream er nede. Pakkeversioner i din komponentbeholdning og de base-images, dine aktuelle images er bygget på, beholdes uanset (se Opbevaring). For alt andet, der skal overleve et langt nedbrud, så hent det mindst én gang inden for din opbevaringsperiode, eller hæv retention_days.

Adgangslog

Hver hentning gennem proxyen vises i din organisations adgangslog for registret med oprindelsen proxy, undtagen to slags rutinemæssig CI-trafik: et CI-jobs tilladte læsninger af metadata (pakkeindekser og versionslister) gemmes ikke siden 2026-10-12, og et CI-jobs downloads, som proxyen udleverer fra sin cache, tælles i optællingen af hentninger pr. dag, version, repository og kørsel siden 2026-10-13. Et CI-jobs downloads, der hentes fra upstream-registret, dets afvisninger og dets fejl er stadig hændelser. Loggen registrerer pakken, versionen og filen, hvem der hentede den (en bruger eller, for CI, jobbets repository), udfaldet og en eventuel beslutning fra politikken. En hentning gennem frem.sh, der udleveres fra cachen, udleveres af proxyen (200); et CI-jobs er en omdirigering til objektlager (307), undtagen Maven-filer op til 1 MiB. Under alle omstændigheder registreres størrelsen. En HEAD-forespørgsel gennem frem.sh registreres som GET, fordi CDN’et videresender HEAD-forespørgsler til fremforge som GET. Afhængighedsscanningens egne læsninger (ovenfor) går ikke gennem CDN’et eller upload-proxyen, så de står ikke i adgangsloggen; fremforge logger dem som antal pr. scanning.

Hvad upstream ser

fremforge kontakter den upstream, du har valgt, på dine vegne. Upstream modtager fremforges IP-adresse og navnet på imaget eller pakken. For docker.io, Red Hats registre og ghcr.io eller quay.io, når du har gemt legitimationsoplysninger til dem, modtager den også din organisations egne legitimationsoplysninger, så hentningen tæller med på din konto der. Den modtager intet om dine brugere. De fleste af disse registre drives af virksomheder uden for EU. Efter den første hentning udleveres hentninger fra fremforges lager i EU uden at kontakte upstream igen, undtagen for at kontrollere tags, npm- og PyPI-metadata, RPM repomd.xml, Maven maven-metadata.xml og NuGet-versionslister og -registrering, Go-versionslister, Helm index.yaml-filer og Cargo-indeksfiler igen (højst hvert 5. minut). Gos checksumdatabase nås også gennem proxyen, på go-kommandoens vegne.

Fejl