Beroendeproxy

Beroendeproxyn är en pull-through-cache för publika register, en per organisation. Du pekar docker, npm, pip, uv, dnf, Maven, NuGet, go, helm eller cargo mot organisationens proxysökväg på frem.sh, och fremforge hämtar från det publika registret åt dig:

• Den första hämtningen av ett image-lager eller en paketfil laddas ned från upstream och kontrolleras mot upstreams egen hash. Om din organisation slår på skanning efter skadlig kod skannas den också med ClamAV medan den strömmas till dig. En fil som inte klarar en kontroll levereras aldrig och lagras aldrig.
• Senare hämtningar levereras från fremforges lagring i EU, för alla medlemmar i organisationen.
• Om upstream ligger nere levereras den senaste fungerande kopian. Taggar, npm-packuments, PyPI-index, RPM repomd.xml, Maven maven-metadata.xml, NuGets versionslistor och registreringar, Gos versionslistor och @latest, Helms index.yaml-filer och Cargos indexfiler besvaras från den senaste fungerande kopian med svarshuvudet X-Fremforge-Proxy: stale. Se Avbrott hos upstream.
• Organisationens paketpolicy och kontrollerna av skadliga paket utvärderas för paket och images som går via proxyn, och varje hämtning registreras i registrets åtkomstlogg. Sedan 2026-10-11 avvisas ett känt skadligt paket eller en känd skadlig image för alla organisationer, och en policy i läget Tvinga avvisar det som bryter mot den; se Vad som tillämpas i dag.

Proxyn är skrivskyddad. Du kan inte pusha till den.

Tillgänglighet och aktivering

Proxyn finns i alla abonnemang och är på som standard för alla organisationer. En organisationsägare kan stänga av den, eller ändra inställningarna, under Bygg och driftsätt › Beroendeproxy eller via API:t (en 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 som aldrig har sparat de här inställningarna har standardvärdet: proxyn är på, och hostade runners hämtar via den (se Hostade runners). När en ägare har sparat dem behåller organisationen exakt det som sparades.

Skanning efter skadlig kod (malware_scan) är av som standard. När den är på skannas varje image-lager, paketfil och diagram som organisationen hämtar via proxyn med ClamAV, även när en annan organisation cachade det först utan att skanna det: den kopian skannas en gång, första gången en organisation som skannar använder den, och resultatet gäller sedan för alla. Paketfiler och diagram skannas innan de levereras; för image-lager, se Container-images. Kända skadliga paket (OSV-meddelanden MAL-*) matchas för alla organisationer, oavsett vad den här inställningen säger. Samma sida och endpoint ställer in block_until_scanned för container-images, som kräver att skanning efter skadlig kod är på (se Container-images), och retention_days (7 till 365, standard 90; se Lagringstid). Ett GET mot endpointen visar om proxyn är på, din användning och ditt tak.

Autentisering

Använd samma inloggningsuppgifter som för paketregistret:

• Personer: en personlig åtkomsttoken med read:package (eller den kortlivade token som fremforge auth ger dina verktyg). Du måste vara medlem i organisationen.
• CI: jobbtoken från Forgejo Actions. En jobbtoken hämtar bara via sitt eget repositorys organisation; alla andra organisationers proxy avvisar den. Jobb från pull requests från forkar får hämta, men aldrig via en upstream som använder organisationens egna inloggningsuppgifter.
• Extern CI, byggvärdar och pull-secrets: en registerrobot med läsåtkomst. Dess token är en read:package-inloggningsuppgift som alla andra.
• fremforges beroendeskanning: nåbarhetsanalysen läser npm-tarballs, PyPI-wheels och Maven-JAR:er via organisationens proxy, på en intern väg som bara skanningstjänsten når. Licenskontrollen, kontrollen av releaseålder och Gos modulgraf läser registermetadata (npm, PyPI, Go, Maven Central, RubyGems och Packagist) på samma sätt. Den är skrivskyddad, kan inte användas utanför fremforge och omfattas av din paketpolicy, cache och ditt lagringstak som alla andra hämtningar.

Hostade runners

Som standard installerar jobb på fremforge-hostade runners via organisationens proxy (runner_pull_through, på som standard). När varje jobb startar pekar runnern npm, pip och uv mot proxyn, och även Go, Maven, NuGet och Trivys sårbarhetsdatabas för de ekosystem som listas i runner_pull_through_ecosystems (alla fyra som standard). Jobbet autentiserar sig med sin egen jobbtoken, så varje installation passerar din paketpolicy och kontrollerna av skadlig kod och finns i åtkomstloggen med jobbets repository. Om proxyn inte går att nå när jobbet startar installerar jobbet i stället från de publika registren via fremforges utgående proxy, och reservvägen loggas. Sätt runner_pull_through till false för att stänga av det här. Se även Paketcacher.

Container-images. För samma jobb hämtar jobbets Docker-daemon också container-images via organisationens proxy: docker pull, docker run, en Dockerfiles FROM, och de jobb- och services:-containrar som runnern startar. Inget i arbetsflödet ändras; image-namnen förblir som de är (ghcr.io/..., quay.io/...), och varje hämtning cachas för din organisation och registreras i åtkomstloggen.

• För alla organisationer: ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws och registry.access.redhat.com.
• Bara med organisationens egna inloggningsuppgifter: docker.io, registry.redhat.io och registry.connect.redhat.com går via proxyn först när en ägare har lagt till organisationens inloggningsuppgifter för det registret under Inloggningsuppgifter för upstream. Jobb från pull requests från forkar använder dem aldrig, så deras hämtningar från de här registren går direkt till registret. Utan inloggningsuppgifter är hämtningar från Docker Hub anonyma och omfattas av Docker Hubs hastighetsgränser.
• Reservväg: proxyn kontrolleras i början av varje jobb. Om den inte går att nå hämtar jobbet varje image direkt från registret, som tidigare, och reservvägen loggas. En enskild hämtning som proxyn inte kan leverera går också vidare till registret.
• En cache, inte en spärr: för images på den här vägen går en hämtning som din paketpolicy eller kontrollen av skadlig kod avvisar också vidare till registret. Där ett avvisande måste stoppa hämtningen, hämta uttryckligen från frem.sh/<org>/dependency-proxy/<registry>/<image> (nedan).
• Omfattas inte: en docker buildx-byggare som använder drivrutinen docker-container kör sin egen BuildKit och hämtar direkt. Standarddrivrutinen docker går via proxyn.

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>

Till exempel:

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 hämta från:

Alla andra värdar avvisas: proxyn hämtar aldrig från en godtycklig URL.

Proxyn listar inte en images taggar. Hostad Renovate föreslår ändå uppdateringar för en image som du refererar till via den här vägen, till exempel en Dockerfiles FROM frem.sh/<org>/dependency-proxy/docker.io/library/python:3.14-slim. Den slår upp nya taggar och digester i upstream-registret och skriver in dem i din referens, som behåller proxysökvägen. Dina byggen fortsätter att hämta via proxyn, så spärrarna för hämtning nedan gäller fortfarande.

Helm-chart som lagras som OCI-artefakter hos de här upstreams kommer via samma väg (Helm 3.8 eller senare):

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

För diagram i ett klassiskt Helm-repository (index.yaml), se Helm-chart.

En tagg kontrolleras mot upstream högst en gång i minuten, med en HEAD-förfrågan, som Docker Hub inte räknar mot sin hämtningsgräns. Image-lager passerar samma spärrar för hämtning som images som pushas till ditt register: med skanning efter skadlig kod på avvisas infekterade eller oskannbara lager, och det gör även images över ditt CVE-tröskelvärde om du har satt block_pull. Skadliga paket inuti en image beskrivs nedan. Som standard levereras en image medan dess lager skannas. Med block_until_scanned svarar den första hämtningen av en image som inte har skannats än, eller av ett lager via digest, 503 med Retry-After tills skanningen är klar, oftast inom några sekunder. Ett lager som någon skanning har funnit infekterat avvisas för alla organisationer.

Medan en förfrågan hämtar och skannar ett lager väntar andra hämtningar av samma lager på den. Om det tar längre än ungefär fyra minuter får de 503 med Retry-After: 30 (this layer is still being fetched and malware-scanned by another request), och ett nytt försök levereras när lagret har lagrats. En skanning som får slut på tid är inget utlåtande: lagret hålls inne, som ett oskannbart lager, men inget resultat registreras. Det läggs i kö hos fremforges bakgrundsskanner för lager, som har en längre tidsbudget, och en senare hämtning levereras när den skanningen har gått igenom.

En paketfil vars skanning får slut på tid (npm, PyPI, RPM, Maven, NuGet, Go, Cargo eller ett Helm-chart) hanteras på samma sätt: den begäran avvisas, inget resultat registreras och filen köas för samma bakgrundsskanner. En senare begäran levereras när skanningen har gått igenom, eller avvisas om den finner filen infekterad. En RPM förblir din organisations egen medan den väntar: den lagras och skannas bara i din organisations eget utrymme, och en annan organisation som hämtar samma RPM hämtar och skannar sin egen kopia.

Storleksgränser. Proxyn levererar inga lager eller filer större än 10 GiB (403). ClamAV läser högst 4 GiB av en fil, så med skanning efter skadlig kod på kan ett större lager eller en större fil inte skannas fullständigt och hålls inne, utom ett modellager i safetensors- eller GGUF-format som klarar sin formatkontroll (se Modellskanning).

Skadliga paket i cachade images

Språkpaketen i varje image som organisationen cachar (npm-, PyPI-, Maven-, Go-, crates-, RubyGems-, NuGet-, Packagist-, Pub- och Hex-paket) matchas mot OSV:s säkerhetsmeddelanden om skadliga paket (MAL-*), samma kontroll som körs på de images du pushar:

• efter att imagen har cachats första gången, oftast inom nästa skanningscykel (ungefär 15 minuter), och
• igen varje dag, så att ett meddelande som publiceras efter att du hämtade imagen ändå hittas.

En träff är ett kritiskt fynd under Säkerhet › Fynd › Beroenden › Skadlig kod, listat som en image med namnet <org>/dependency-proxy/<upstream>/<repository> och den digest som bär det, och det skickas till dem som tar emot organisationens säkerhetsaviseringar. Att avfärda det fungerar som för alla fynd om skadlig kod, med en motivering och ett valfritt slutdatum. Fyndet stängs av sig självt när organisationen inte längre cachar den imagen, till exempel efter att lagringstiden har tagit bort den.

En hämtning av en image med ett öppet, icke avfärdat fynd avvisas med 403 DENIED, som för pushade images, och loggas i åtkomstloggen som blocked med orsaken image_malware. Avvisas sedan 2026-10-11; dessförinnan levererades en sådan hämtning och registrerades som would_block.

Inloggningsuppgifter för upstream

Docker Hub (docker.io) och Red Hats register (registry.redhat.io och registry.connect.redhat.com, Red Hats certifierade partner-images) hämtas via beroendeproxyn bara med organisationens eget konto. För GitHub (ghcr.io) och Quay (quay.io) är inloggningsuppgifter valfria: utan dem hämtas de anonymt, vilket ger publika images; lägg till dem för att hämta dina privata images. En organisationsägare lägger till inloggningsuppgifterna under Bygg och driftsätt › Beroendeproxy › Inloggningsuppgifter för upstream, eller via API:t på /_app/api/v1/orgs/<org>/dependency-proxy/upstreams. Godkända former:

• Docker Hub: ditt användarnamn plus en personlig åtkomsttoken, eller en åtkomsttoken för organisationen med Docker-organisationens namn som användarnamn.
• Red Hat: ett tjänstekonto för registret (ett användarnamn som 1234567|ci, plus dess token), eller dess pull-secret för OpenShift. Lägg till det en gång per Red Hat-register du hämtar från; varje register behåller bara sin egen post i pull-secreten.
• GitHub (ghcr.io): ditt användarnamn på GitHub plus en personlig åtkomsttoken (classic) med read:packages.
• Quay (quay.io): ett robotkonto (organisation+robot) plus dess token, eller quay.io-posten i en pull-secret från Red Hat.

Red Hats register med dina inloggningsuppgifter, och privata images på ghcr.io och quay.io, stöds men är inte verifierade från början till slut än: fremforge har testat dem mot registrens tokenflöde, men har inget konto att hämta med.

När inloggningsuppgifter för ghcr.io eller quay.io har lagrats använder varje hämtning från det registret dem, även för publika images, och cachas bara för din organisation. Jobb från pull requests från forkar använder dem aldrig: de hämtar från de två registren anonymt och får därför bara publika images.

Hemligheten lagras krypterad och används bara av beroendeproxyn, för din egen organisations hämtningar. Den visas aldrig igen; du ser ett fingeravtryck i stället. Testa anslutningen kontrollerar den och visar, för Docker Hub, hur många hämtningar som återstår i det aktuella gränsfönstret.

Images som hämtats med dina inloggningsuppgifter cachas bara för din organisation och levereras aldrig till en annan organisation. Jobb från pull requests från forkar kan inte hämta via ett register som kräver dina inloggningsuppgifter. Om inloggningsuppgifterna går ut fortsätter redan cachade images att levereras, och statusen visar Nekad av registret. Utan inloggningsuppgifter avvisas en hämtning från Docker Hub med ett meddelande som säger just det.

Kubernetes och OpenShift

Peka en spegel mot proxyn. 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 en ImageTagMirrorSet (och en ImageDigestMirrorSet för 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

Klustrets pull-secret behöver en frem.sh-token med read:package.

npm

.npmrc i ditt projekt eller i din hemkatalog:

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

Använd sedan npm, pnpm eller yarn som vanligt. Paketen kommer från registry.npmjs.org, även paket med scope. Varje tarball måste matcha den integrity (sha512) som npm-registret publicerar för den innan den levereras.

npm audit och pnpm audit fungerar mot proxyn. De besvaras från fremforges egen kopia av OSV:s databas med säkerhetsmeddelanden, så din beroendelista skickas inte till någon tredjeparts tjänst för säkerhetsmeddelanden. Klienter som stöds och svarsformatet beskrivs under npm audit och pnpm audit via beroendeproxyn.

För att kombinera proxyn med paket som organisationen publicerar i sitt eget register, skicka ditt scope till registret och allt annat till proxyn:

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 inloggningsuppgifterna i en netrc-fil eller en nyckelring i stället för i URL:en. Indexet levereras i båda formaten som installerare använder (PEP 503 HTML och PEP 691 JSON), med varje fils sha256, requires-python, yank-status och PEP 658-metadata. Varje fil måste matcha den sha256 som PyPI listar för den innan den levereras.

Använd proxyn som ditt enda index. Lägg inte till den med --extra-index-url (eller PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL) bredvid ett annat index, och inte heller ett annat index bredvid den: att blanda index är det som gör attacker med beroendeförväxling möjliga, eftersom installeraren tar ett namn från det index som erbjuder det. För att installera paket som organisationen publicerar i sitt eget register, kör en separat installation med det registret som enda index och --no-deps, eller, med uv, fäst vart och ett av dem vid det med namn (explicit = true och [tool.uv.sources]).

RPM (dnf och yum)

Varje repository nås på

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

I dag är upstream cdn-ubi.redhat.com, Red Hats repositories för Universal Base Image (UBI 8, 9 och 10: BaseOS, AppStream och CodeReady Builder, för alla arkitekturer som Red Hat publicerar), under content/public/ubi/. De kräver inget Red Hat-konto. En .repo-fil för 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 skickar username och password som HTTP Basic-autentisering. Använd en registerrobot för byggvärdar och image-byggen, och gör filen läsbar bara för root (chmod 600), eftersom den innehåller token. I ett containerbygge, stäng av imagens egna repositories för installationen (dnf --disablerepo='*' --enablerepo='*-fremforge' install …), så att inget hämtas förbi proxyn.

Vad proxyn gör:

• repodata/repomd.xml kontrolleras mot upstream högst var 5:e minut och levereras exakt som upstream publicerade den. En ny repomd.xml godtas först när den primary.xml som den anger har laddats ned och matchar den sha256 och storlek som repomd.xml anger för den. Fram till dess, och medan upstream ligger nere, levereras den föregående.
• Repositoryts metadatafiler (primary, filelists, other, updateinfo, modules, comps och sqlite-varianterna) måste matcha sha256 och storlek i repomd.xml.
• Paket måste matcha sha256 och storlek i primary.xml. Med skanning efter skadlig kod på skannas varje paket också inuti sin komprimerade payload, inte bara som fil, och dess installationsskript skannas också. Ett paket som skannern inte kan öppna avvisas då i stället för att levereras oskannat.
• Paketsignaturer kontrolleras av dnf själv (gpgcheck=1), mot Red Hats nyckel, precis som utan proxyn. Proxyn ändrar aldrig ett paket eller repositoryts metadata.
• RPM-innehåll cachas bara för din organisation. En annan organisation som hämtar samma paket hämtar och lagrar sin egen kopia. Det är så att samma kodväg senare kan leverera Red Hat-innehåll som hämtats med ditt eget Red Hat-abonnemang, som aldrig får nå en annan kund.

Ett repository som använder någon annan kontrollsumma än sha256 levereras inte. Att proxa cdn.redhat.com med ditt Red Hat-berättigandecertifikat är planerat och finns inte än.

Maven

Maven Central nås på

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

Gör den till spegel för alla repositories i ~/.m2/settings.xml (eller den settings.xml som ditt bygge använder), med inloggningsuppgifterna i en <server> med samma 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 skickar användarnamn och lösenord som HTTP Basic-autentisering när proxyn ber om dem. För att använda proxyn tillsammans med paket som organisationen publicerar i sitt eget register, skriv <mirrorOf>*,!fremforge</mirrorOf> och deklarera ditt register (https://frem.sh/api/packages/<org>/maven) som repository fremforge med en 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()
            }
        }
    }
}

Vad proxyn gör:

• maven-metadata.xml kontrolleras mot Maven Central högst var 5:e minut. En ny kopia godtas bara när den matchar Maven Centrals egen .sha1 för den. Fram till dess, och medan Maven Central ligger nere, levereras den föregående kopian. Dess .sha1, .md5, .sha256 och .sha512 beräknas från den kopia du får, så de matchar den alltid.
• Artefakter (jar-filer, POM:er, .module-filer och alla andra filer i en release) måste matcha Maven Centrals .sha1 och, när Maven Central publicerar en, dess .sha256. En fil som saknar båda kontrollsummorna hämtas inte. Med skanning efter skadlig kod på skannas varje fil medan den strömmas till dig. En jar-fil öppnas också: en post som skannern inte kan packa upp själv (zstd) packas upp åt den, och en jar-fil med en post som ingen av dem kan öppna (till exempel LZMA) avvisas i stället för att levereras oskannad.
• Last-Modified är tidpunkten då Maven Central publicerade filen, även när den kommer från cachen, så att Renovates minsta releaseålder och andra verktyg som läser den ser den verkliga releasetiden. En fil som Maven Central skickade utan en sådan får ingen Last-Modified alls, aldrig tidpunkten då fremforge cachade den. Ett HEAD mot en cachad fil svarar 200 med dess Content-Length och denna Last-Modified.
• Kontrollsummefiler (.sha1, .sha256, …) och signaturer (.asc) för artefakter skickas vidare oförändrade. Kontrollera signaturer med ditt byggets PGP-plugin, som du skulle göra utan proxyn.
• Snapshots levereras inte. Maven Central publicerar inga, och en snapshot kan ändras under samma version. En -SNAPSHOT-förfrågan besvaras med 404, så att ditt bygge går vidare till det repository som har den.

För paketpolicyn heter ett Maven-paket groupId:artifactId. Dess releasetid är när Maven Central publicerade filen, och dess licens är de <licenses> som dess POM deklarerar. En licens som ärvs från en föräldra-POM slås inte upp, så den räknas som inte bedömd.

NuGet

Paketkällan är proxyns tjänsteindex:

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

nuget.config bredvid 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 proxyn till den enda källan, så att inget paket hämtas förbi den. NuGet expanderar %FREMFORGE_TOKEN% från miljön, så token behöver inte stå i filen. Använd sedan dotnet restore, dotnet add package <id> --version <version> eller nuget install som vanligt.

Vad proxyn gör:

• Tjänsteindexet listar bara resurser på frem.sh: paketinnehållet (flat container) och paketregistreringen. Sökning tillhandahålls inte, eftersom restore och install inte behöver den. dotnet add package utan --version behöver sökning, så ange versionen.
• Versionslistor och registrering kontrolleras mot nuget.org högst var 5:e minut, och den senaste fungerande kopian levereras medan nuget.org ligger nere.
• Paket (.nupkg) måste matcha den SHA-512 och storlek som nuget.orgs katalog registrerar för releasen innan de levereras. En release vars katalogpost saknar hash hämtas inte. Med skanning efter skadlig kod på skannas varje paket medan det strömmas till dig, både inuti paketet och som fil.
• Paketsignaturer kontrolleras av NuGet-klienten själv, precis som utan proxyn. Proxyn ändrar aldrig ett paket.

För paketpolicyn namnges ett NuGet-paket med sitt id i gemener. Dess releasetid och licens är nuget.orgs published-datum och paketets deklarerade licensuttryck. Ett paket som deklarerar sin licens som en fil eller en URL räknas som inte bedömt.

Go-moduler

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

Autentiseringen kommer från ~/.netrc (_netrc på Windows), som go-kommandot läser för frem.sh. Gör filen läsbar bara för dig (chmod 600 ~/.netrc):

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

Använd GOPROXY=https://frem.sh/_app/proxy/<org>/go i stället för att lägga till ,direct: med direct hämtas en modul som proxyn inte levererar från sitt källrepository förbi proxyn.

Vad proxyn gör:

• @v/list och @latest kontrolleras mot proxy.golang.org högst var 5:e minut, och den senaste fungerande kopian levereras medan den ligger nere.
• .mod och .zip måste matcha de h1:-hashar som Gos kontrollsummedatabas (sum.golang.org) har signerat för den modulversionen. Proxyn verifierar databasens signatur med samma nyckel som är inbyggd i go-kommandot. En modul-zip packas upp och hashas på samma sätt som go-kommandot hashar den innan den levereras. En modul som kontrollsummedatabasen inte känner till levereras inte. Med skanning efter skadlig kod på skannas varje zip medan den strömmas till dig.
• Kontrollsummedatabasen nås också via proxyn. go-kommandot frågar proxyn om den levererar sum.golang.org och hämtar sedan varje uppslag och tile via den. Så GOSUMDB förblir på och gör fortfarande sin egen fullständiga verifiering, inklusive de bevis som proxyn själv inte upprepar, och din maskin behöver ingen direkt åtkomst till sum.golang.org.
• Privata moduler levereras inte: proxy.golang.org kan inte hämta dem, och kontrollsummedatabasen känner inte till dem. Undanta dem med GOPRIVATE (eller GONOPROXY och GONOSUMDB), så hämtar go-kommandot dem från din egen Git-hosting som tidigare.
• Moduler som hostas på frem.sh efterfrågas aldrig hos Google. En förfrågan om en modul under frem.sh (eller en underdomän) avvisas med 404 innan proxyn kontaktar någon, eftersom förfrågan i sig skulle avslöja modulens sökväg för proxy.golang.org och sum.golang.org. Lägg frem.sh i GOPRIVATE så att go-kommandot hämtar de modulerna direkt från frem.sh.

Vad som når Google för publika moduler

Proxyn hämtar publika Go-moduler från Googles modulspegel (proxy.golang.org) och kontrollerar dem mot Googles kontrollsummedatabas (sum.golang.org). När en modul eller version inte är cachad än tar Google därför emot:

• modulsökvägen och versionen som hämtas (till exempel github.com/gorilla/websocket@v1.5.0), och uppslagen i kontrollsummedatabasen för den;
• förfrågningar från fremforges utgående adresser, inte från dina maskiner, utan din organisations namn, användare, token eller repository.

Google tar inte emot din kod, din go.mod, namnen på dina repositories eller vilken organisation som frågade. En modul som redan är cachad levereras utan att Google kontaktas. Samma sak gäller säkerhetsskannrarna: de läser publika Go-moduler via den här proxyn, och de frågar aldrig efter en modul som är privat enligt reglerna ovan.

För paketpolicyn namnges en Go-modul med sin modulsökväg. Dess releasetid är den tidpunkt som proxy.golang.org registrerar för versionen. Go-moduler deklarerar ingen licens som proxyn kan läsa, så licensregler gäller inte för dem.

Helm-chart

Klassiska Helm-repositories (en index.yaml och diagramarkiv) levereras från en fast lista:

Lägg till ett repository med proxyns URL och inloggningsuppgifter 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

Varje diagram-URL i indexet pekar tillbaka till frem.sh, så Helm skickar dina inloggningsuppgifter med varje nedladdning av diagram och --pass-credentials behövs inte.

Vad proxyn gör:

• index.yaml kontrolleras mot repositoryt högst var 5:e minut, och den senaste fungerande kopian levereras medan repositoryt ligger nere eller svarar med något som inte är ett Helm-index. Proxyn returnerar det som JSON, som Helm läser som YAML.
• Diagram måste matcha den digest (sha256) som repositoryts index registrerar för den versionen innan de levereras. En version vars indexpost saknar digest, eller vars diagram inte ligger på repositoryts egna värdar (till exempel en oci://-URL), utelämnas ur det index du får. Med skanning efter skadlig kod på skannas varje diagram medan det strömmas till dig.
• Provenance-filer (.prov) skickas vidare oförändrade, så helm pull --verify och helm install --verify fungerar med diagramutgivarens publika nyckel, till exempel för cert-manager: helm pull jetstack/cert-manager --version v1.21.2 --verify --keyring cert-manager-keyring.gpg. En provenance-fil måste namnge diagrammet med indexets digest, annars levereras den inte. Av de fyra repositoryna publicerar jetstack och prometheus-community provenance-filer; för ett diagram utan en sådan misslyckas --verify med failed to fetch provenance (404).
• Ett diagrams beroenden löses upp av Helm från de repositories som dess Chart.yaml anger. En helm dependency update når de repositoryna direkt om du inte också lägger till dem via proxyn.

Bitnamis klassiska repository finns inte på listan: dess aktuella diagramversioner är OCI-artefakter på Docker Hub. Hämta dem via containervägen, oci://frem.sh/<org>/dependency-proxy/docker.io/bitnamicharts/<chart>, som använder organisationens egna inloggningsuppgifter för Docker Hub (ovan).

För paketpolicyn namnges ett diagram med sitt diagramnamn. Dess releasetid är created-datumet i indexet, och dess licens är annoteringen artifacthub.io/license, om diagrammet har en.

Cargo (crates.io)

Proxyn är ett sparse registry för crates.io. Den kräver Cargo 1.74 eller senare. Ersätt crates-io med den i .cargo/config.toml, i ditt projekt eller i ~/.cargo/config.toml för alla projekt:

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

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

Cargo skickar token som hela Authorization-huvudet, så ge den prefixet Bearer. Håll den utanför filen, i miljön:

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

Med källersättningen kommer varje crate från crates.io via proxyn, även de crates som en befintlig Cargo.lock fäster, och ingen crate hämtas förbi den.

Vad proxyn gör:

• config.json är proxyns egen. Den pekar nedladdningar av crates tillbaka till organisationens sökväg på frem.sh och talar om för Cargo att registret kräver autentisering, så att Cargo skickar token med varje förfrågan om index och nedladdning.
• Indexfiler kommer från index.crates.io. De kontrolleras igen högst var 5:e minut, och den senaste fungerande kopian levereras medan crates.io ligger nere. Varje fil är crates.ios egen, version för version. Yankade versioner finns kvar i den, markerade som yankade: Cargo använder fortfarande en som din Cargo.lock fäster, och väljer ingen sådan vid en ny upplösning.
• Crates (.crate) kommer från static.crates.io och måste matcha cksum (sha256) i sin indexpost innan de levereras. En version vars indexpost saknar kontrollsumma utelämnas. Med skanning efter skadlig kod på skannas varje crate medan den strömmas till dig, även inuti arkivet. Cargo kontrollerar samma kontrollsumma igen på sin sida.
• Sökning, publicering, yankning och ägare tillhandahålls inte: cargo search svarar 404 och cargo publish avvisas med 405. Publicera dina egna crates i organisationens Cargo-register.

För paketpolicyn namnges en crate med sitt namn så som crates.io publicerar det, och dess releasetid är pubtime i dess indexpost. Indexet innehåller ingen licens, så licensregler gäller inte för crates. Sårbarheter och skadliga crates kommer från OSV:s data för crates.io: RustSec-meddelandena och MAL-*-posterna.

Terraform- och OpenTofu-moduler

Proxyn levererar publika moduler från modulregistren och från publika git-repositories, så att tofu init och terraform init hämtar dem från fremforges cache i stället för från internet. Den omfattar:

• Registermoduler från registry.opentofu.org och registry.terraform.io, till exempel terraform-aws-modules/vpc/aws eller Azure Verified Modules (Azure/avm-*).
• Git-källor på github.com och gitlab.com vid en tagg eller en commit, till exempel git::https://github.com/<owner>/<repo>.git?ref=v1.2.3 eller github.com/<owner>/<repo>?ref=v1.2.3.

En branch avvisas: en cachad modul måste förbli densamma, så ange en tagg eller en commit. Privata repositories, andra värdar och SSH-källor levereras inte.

IaC-kontrollen läser moduler via den här cachen för alla organisationer, även en vars beroendeproxy är avstängd. Modulcachenyckeln, som din egen CI behöver, kan för närvarande bara skapas i fremforges interna organisationer: för alla andra organisationer visas inte avsnittet i konsolen, och API:t svarar 404.

Modulcachenyckeln

OpenTofu och Terraform når cachen via organisationens modulcachenyckel, som placeras i URL:en. En organisationsägare skapar den under Bygg och driftsätt › Beroendeproxy › Terraform- och OpenTofu-moduler. Nyckeln visas en gång, som en konfiguration för OpenTofu och en för Terraform som är redo att klistra in. Därefter visar sidan bara dess första tecken, dagen då den senast användes och knappen Rotera. Efter en rotation fortsätter den föregående nyckeln att fungera i 24 timmar, så att pågående pipelines hinner bli klara; därefter behöver varje CI-konfiguration den nya. Att skapa och rotera en nyckel registreras i granskningsloggen och når din SIEM som andra granskningshändelser.

Nyckeln kan också skapas och roteras via API:t, med en token som har policy:write: GET /orgs/{org}/dependency-proxy/module-key visar dess prefix och datum (aldrig nyckeln), och POST /orgs/{org}/dependency-proxy/module-key med {"expect": "<current prefix>"} (eller "" när det inte finns någon) svarar med den nya nyckeln en gång. Om en annan nyckel har blivit aktuell under tiden blir svaret 409 module-key-stale och inget ändras.

Nyckeln ger rätt att läsa publika moduler som din organisation, och inget annat. Behandla den som ett lösenord: förvara den i dina CI-secrets, inte i ett repository.

Registermoduler: inga ändringar i dina källor

Peka OpenTofus register mot cachen med en CLI-konfigurationsfil (~/.tofurc, eller den fil som TF_CLI_CONFIG_FILE anger). Dina source- och version-rader förblir som de är:

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

• Behåll båda raderna. host-blocket ersätter allt som OpenTofu vet om registret. Utan providers.v1 misslyckas varje installation av providers med “does not offer a OpenTofu provider registry”.
• Lägg inte till något credentials-block. OpenTofu och Terraform matchar inloggningsuppgifter mot registrets värdnamn, så en token i ett sådant block skulle också skickas till det publika registret: med varje förfrågan om providers, och med varje förfrågan på en maskin där host-blocket saknas. Modulcachenyckeln behöver inget credentials-block.
• Terraform: skriv registry.terraform.io i stället för registry.opentofu.org på alla tre ställena. Vi har verifierat den här konfigurationen på OpenTofu 1.13.1, med en nyckel och med en felaktig (403 Forbidden). Terraform dokumenterar samma beteende för värd och inloggningsuppgifter; det har vi inte mätt.

För att kontrollera att cachen används, kör TF_LOG=debug tofu init och leta efter rader med GET https://frem.sh/_app/proxy/<org>/terraform/... för dina moduler.

Git-källor

Ange proxyns arkiv för taggen eller commiten som en HTTPS-källa. //* väljer modulens rot i arkivet, och en underkatalog följer efter den:

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

Inga inloggningsuppgifter behövs utöver modulcachenyckeln i URL:en.

Vad proxyn gör

• En version fästs vid första hämtningen. Proxyn löser upp taggen till en commit från repositoryts egen lista över git-referenser (det som git ls-remote läser), hämtar den commitens arkiv och registrerar commiten och arkivets SHA-256. Varje senare förfrågan, från vilken organisation som helst, får exakt de bytena. En version av en registermodul fästs vid den commit som dess tagg pekade på.
• En flyttad tagg ändrar inte din modul. Proxyn kontrollerar fästa taggar igen högst var 6:e timme. Om en tagg nu pekar på en annan commit fortsätter proxyn att leverera den fästa och registrerar att upstream-taggen har flyttats. Bara en operatör hos fremforge kan fästa om en modul.
• Vad det här skyddar mot, och vad det inte skyddar mot. Register och git-värdar publicerar ingen kontrollsumma för modularkiv, så den första hämtningen är betrodd. Inget som ändras upstream efter det når dig: en ompekad tagg eller ett omgenererat arkiv levereras inte. En version som var skadlig när den först publicerades levereras som den var.
• Arkiv kontrolleras innan de levereras. Ett arkiv som är större än 50 MiB, packas upp till mer än 512 MiB eller 20 000 poster, eller innehåller en absolut sökväg, en ..-sökväg, en enhetsfil eller en länk som pekar utanför arkivet avvisas, och inget lagras.
• Skanning efter skadlig kod gäller för modularkiv som för andra filer när organisationen har den på. OSV har inget Terraform-ekosystem, så ingen lista över kända skadliga paket gäller för moduler, och paketpolicyns regler för licens och releaseålder tillämpas inte på dem.
• Delad lagring, loggning per organisation. En publik modul lagras en gång för alla. Varje organisations hämtningar registreras i dess egen åtkomstlogg, med aktören module-cache-key. Själva modulcachenyckeln skrivs aldrig till någon logg.

Paketpolicy och skadliga paket

Organisationens paketpolicy utvärderas för npm-, PyPI-, RPM-, Maven-, NuGet-, Go- och Cargo-paket och Helm-chart som hämtas via proxyn, med samma regler som för paket i ditt register:

• Licens: listor för tillåtna, nekade och varnade licenser, tillämpade på versionens deklarerade licens.
• Sårbarheter på eller över ditt tröskelvärde för allvarlighetsgrad eller CVSS, från OSV-databasen.
• Spärr- och tillåtelselistor efter paketnamn och versionsintervall.
• Minsta releaseålder, från upstreams publiceringstid.
• Skadliga paket (OSV-meddelanden MAL-*) kontrolleras alltid, oavsett vad policyn säger.

För RPM-paket är versionen [epoch:]version-release, licensen är paketets License-fält och releaseåldern är när paketet kom in i repositoryt. OSV har inga data om skadliga paket eller sårbarheter för RPM-paket, så de två kontrollerna gäller inte för RPM:er i proxyn. Sårbarheter i RPM-paket hittas när de images som byggs från dem skannas. Detsamma gäller för Helm-chart: OSV har inga data för dem, så licens, spärrlistor och releaseålder gäller, och de images som ett diagram driftsätter skannas där de hämtas. När avvisning har slagits på finns en blockerad diagramversion kvar i Helm-indexet, och nedladdningen av den avvisas med 403.

Avvisning är på sedan 2026-10-11. En policy i läget Tvinga tar bort en blockerad version från npm-packumentet eller PyPI-indexet, så att din resolver väljer en tillåten version, och en direkt nedladdning av den avvisas med 403 som anger regeln. En policy i läget Skugga, som är standard, levererar fortfarande paketet och registrerar hämtningen i åtkomstloggen som would_block med den regel som matchade. Skadliga paket avvisas oavsett policyns läge, även Skugga och Av, och utelämnas ur den paketmetadata som proxyn levererar.

Så länge proxyn inte kan få ett policysvar från fremforge (efter några sekunders nya försök, och utan ett nyligt svar för samma paket att falla tillbaka på), avvisar den nedladdningen med 503 i stället för att leverera en version som den inte kunde kontrollera efter skadlig kod. Ett nytt försök senare lyckas när svaret är tillbaka.

Data om säkerhetsmeddelanden uppdateras från fremforges OSV-spegel flera gånger om dagen, och en policyändring gäller från nästa hämtning. Inget behöver skannas om.

Vad som tillämpas i dag

Cachade images skannas också efter sårbarheter och läckta hemligheter som de images du pushar; se Image-skanning.

Känt utnyttjade sårbarheter

Sedan 2026-10-13 kontrollerar fremforge varje paketversion som går via proxyn mot de sårbarheter som är kända för att utnyttjas i praktiken: ENISA:s EU Vulnerability Database (EUVD) först, med CISA:s katalog Known Exploited Vulnerabilities som tillägg. En version räknas bara när en sådan sårbarhet påverkar den och det finns en åtgärdad version, så det finns alltid en version att byta till. Det är samma regel som fremforge redan tillämpar på sina egna runner-images.

Sedan 2026-10-31 avvisas en sådan version. En nedladdning svarar 403 med ett meddelande som namnger CVE:erna och ber dig uppgradera, och svaret har x-fremforge-proxy-policy: blocked;package_policy:known_exploited. Versionen utelämnas också ur de paketmetadata som proxyn levererar, så ett versionsintervall väljer en annan version i intervallet; bara en låsfil eller byggfil som låser den berörda versionen misslyckas. Avvisningen registreras i din åtkomstlogg som alla andra policyavvisningar.

Det här är en plattformsregel, som för skadliga paket: den gäller oavsett policyns läge, och policyns undantag häver den inte. Din organisations egen bot för beroendeuppdateringar ser fortfarande dessa versioner i metadata, så att den kan föreslå uppgraderingen. fremforges egna skannrar för pull requests läser dem också fortfarande, så att ett känt utnyttjat beroende fortfarande visas som ett fynd i stället för att försvinna ur skanningen.

Om ett bygge misslyckas på den, byt till den åtgärdade versionen: en pull request med en säkerhetsfix kan redan vara öppen. Mätt från 2026-10-13 till 2026-10-31, före omläggningen, laddade ingen kundorganisation ned en sådan version.

Samma flöde låter redan en version som åtgärdar en känt utnyttjad sårbarhet hoppa över policyns minsta releaseålder.

Lagring, tak och fakturering

Cachade filer räknas mot organisationens paketlagring med full storlek, som om de låg i ditt eget register. Ett containerlager eller en npm- eller PyPI-fil som flera organisationer hämtar lagras en gång, men varje organisations användning räknar den. RPM-innehåll lagras per organisation (se RPM).

• Betalda abonnemang: cachade filer delar en gemensam pool för paketlagring med dina egna paket. Med överförbrukning avstängd får proxyn använda det som dina egna paket lämnar kvar av poolen. När inget finns kvar avvisas nya hämtningar med 403 (dependency proxy storage cap reached), och det som redan är cachat levereras fortfarande. Med överförbrukning på finns inget tak för proxyn, och lagring utöver poolen faktureras enligt priset för överförbrukning av paketlagring.
• Provperioder: fast 5 GB cachade filer.

Sidan Beroendeproxy visar din användning och ditt tak. Siffran för dina egna paket som taket beräknas från uppdateras en gång om dagen.

Lagringstid

En cachad fil som organisationen inte har hämtat på retention_days (standard 90, från 7 till 365) tas bort från din cache, tillsammans med de taggar som pekar på den, och slutar räknas mot din lagring. Kontrollen körs varje timme. När ingen organisation längre refererar till en fil raderas den från fremforges lagring 24 timmar senare. En ny hämtning laddar ned den från upstream igen.

Paketversioner som fortfarande används behålls. En paketfil (npm, PyPI, Maven, NuGet, Go, Cargo, Helm eller RPM) tas inte bort, oavsett hur länge sedan den senast hämtades, så länge samma paketversion är en aktuell komponent i organisationens komponentinventering: i den aktuella SBOM:en för ett repositorys standardbranch, dess senaste release, en aktuell image, ett aktivt registerpaket eller en uppladdad SBOM. Ett beroende som är fäst i en låsfil men bara byggs två gånger om året finns därför kvar i cachen. Det räknas fortfarande mot din lagring. När versionen lämnar alla aktuella SBOM:er gäller den vanliga regeln igen vid nästa timkontroll.

Basimages som dina aktuella byggen använder behålls. En cachad container-image tas inte bort, oavsett hur länge sedan den senast hämtades, så länge en av organisationens aktuella images är byggd på den: varje lager i den cachade imagen är också ett lager i en image som fortfarande publiceras under en tagg i organisationens register. Imagens manifest, dess konfiguration och alla dess lager behålls tillsammans, så att en hämtning av den fortsätter att fungera, och detsamma gäller ett index för flera plattformar vars plattforms-image du bygger på. En image som bara delar ett lager med dina byggen (till exempel en annan image på samma distribution) behålls inte enligt den här regeln. Den räknas fortfarande mot din lagring. När ingen aktuell image längre är byggd på den gäller den vanliga regeln igen. Alla andra cachade images följer regeln om senaste hämtning. Två fall känns inte igen och följer regeln om senaste hämtning: en bas som bara används för en annan plattform än linux/amd64, och ett bygge som komprimerar om basimagens lager i stället för att återanvända dem.

Avbrott hos upstream

När ett upstream-register ligger nere, är långsamt eller avvisar förfrågningar fortsätter byggena att fungera för allt som din organisation har hämtat tidigare:

• Filer som du har hämtat tidigare (image-lager, .tgz, wheels, .jar, .nupkg, Go .zip och .mod, Helm-chart, crates) levereras från fremforges lagring. Leveransen väntar aldrig på upstream.
• Index och taggar (image-taggar, npm-packuments, PyPI-index, RPM repomd.xml, Maven maven-metadata.xml, NuGets versionslistor och registreringar, Go @v/list och @latest, Helm index.yaml, Cargos indexfiler) besvaras från den senaste fungerande kopian. Svaret har då X-Fremforge-Proxy: stale, så en ny release som publiceras under avbrottet syns inte förrän upstream är tillbaka.
• Image-taggar som en annan organisation har cachat levereras också från den senaste fungerande kopian, när din organisation aldrig har hämtat den taggen: bara för publika images som hämtats utan inloggningsuppgifter, och bara från fremforges delade lagring, aldrig från innehåll som en annan organisation hämtat med sina egna inloggningsuppgifter för register. Images från Docker Hub hämtas alltid med organisationens egna inloggningsuppgifter och delas inte på det här sättet.
• Allt som aldrig har hämtats tidigare svarar 502, eftersom det inte finns något att leverera.

Om fremforges egen inloggnings- eller behörighetstjänst är otillgänglig en kort stund fortsätter förfrågningar som tilläts under de senaste 15 minuterna att levereras från cachen (bara läsningar). En återkallad token eller ett borttaget medlemskap får ändå verkan så snart fremforge kan kontrollera det.

Vad som klarar ett avbrott begränsas av lagringstiden. En fil som organisationen inte har hämtat på retention_days (standard 90) tas bort. Därefter måste den hämtas från upstream igen, vilket inte är möjligt medan upstream ligger nere. Paketversioner i din komponentinventering, och de basimages som dina aktuella images är byggda på, behålls ändå (se Lagringstid). För allt annat som du behöver ska klara ett långt avbrott: hämta det minst en gång inom din lagringstid, eller höj retention_days.

Åtkomstlogg

Varje hämtning via proxyn visas i organisationens åtkomstlogg för registret med ursprunget proxy, utom två slags rutinmässig CI-trafik: ett CI-jobbs tillåtna metadataläsningar (paketindex och versionslistor) lagras inte sedan 2026-10-12, och ett CI-jobbs nedladdningar som proxyn levererar från sin cache räknas i hämtningsräkningen per dag, version, repository och körning sedan 2026-10-13. Ett CI-jobbs nedladdningar som hämtats från upstream-registret, dess avvisningar och dess fel är fortfarande händelser. Loggen registrerar paketet, versionen och filen, vem som hämtade det (en användare, eller för CI jobbets repository), utfallet och eventuella policybeslut. En hämtning via frem.sh som levereras från cachen levereras av proxyn (200); ett CI-jobbs hämtning är en omdirigering till objektlagring (307), utom Maven-filer upp till 1 MiB. I båda fallen registreras storleken. En HEAD-förfrågan via frem.sh registreras som GET, eftersom CDN:et vidarebefordrar HEAD-förfrågningar till fremforge som GET. Beroendeskanningens egna läsningar (ovan) passerar inte CDN:et eller uppladdningsproxyn, så de finns inte i åtkomstloggen; fremforge loggar dem som antal per skanning.

Vad upstream ser

fremforge kontaktar den upstream du har valt, för din räkning. Upstream tar emot fremforges IP-adress och namnet på imagen eller paketet. För docker.io, Red Hats register, och ghcr.io eller quay.io när du har lagrat inloggningsuppgifter för dem, tar den också emot din organisations egna inloggningsuppgifter, så att hämtningen räknas mot ditt konto där. Den tar inte emot något om dina användare. De flesta av de här registren drivs av företag utanför EU. Efter den första hämtningen levereras hämtningar från fremforges lagring i EU utan att upstream kontaktas igen, utom för att kontrollera taggar, npm- och PyPI-metadata, RPM repomd.xml, Maven maven-metadata.xml och NuGets versionslistor och registrering, Gos versionslistor, Helms index.yaml-filer och Cargos indexfiler (högst var 5:e minut). Gos kontrollsummedatabas nås också via proxyn, för go-kommandots räkning.

Fel