Fullständig dataexport

Du kan exportera din organisations data när du vill från administrationsgränssnittet: varje repo som ett git bundle, issues, pull requests, kommentarer, etiketter, milstolpar och releaser för varje repo, din paketinventering, dina skanningsfynd och beslut från paketpolicyn, dina bygg- och release-attesteringar med sina signaturer, SBOM:erna för dina repon och container-images samt granskningsspåret för de senaste 90 dagarna. Allt är i standardformat och laddas ner som en enda .tar.gz med ett signerat SHA-256-manifest som täcker varje fil.

Den här sidan beskriver vad paketet innehåller, hur du verifierar det och vilka gränser som gäller. Exporten ingår i planen för 30 €/användare; ingen Enterprise-nivå krävs.

Vad paketet innehåller

Paketets struktur, varje fil i det och formen på varje post beskrivs på en enda sida: Exportschema. Kort sagt: ett git bundle per repo; issues, pull requests, kommentarer, etiketter, milstolpar, releaser och inställningar för varje repo som NDJSON; din paketinventering och fillista; din inventering av tredjepartskomponenter; din åtkomstlogg för registret; dina skanningsfynd, beslut från paketpolicyn och signerade attesteringar; SBOM:erna för dina repon och container-images; och ditt granskningsspår, allt under ett DSSE-signerat SHA-256-manifest. Paketinnehåll levereras på begäran som ett andra arkiv, se §“Paketinnehåll”.

Paketinnehåll

Kryssa i Ta med paketinnehåll när du startar en export (eller skicka {"include_packages": true} till API:t) så tar exporten fram ett andra arkiv bredvid paketet: varje fil i varje paketversion som din organisation äger, läst från registrets lagring när exporten körs.

export-<your-org-slug>-<timestamp>.packages.tar
└── packages/
    ├── npm/<name>/<version>/<file>               — e.g. npm/@acme/lib/1.2.0/lib-1.2.0.tgz
    ├── npm/<name>/<version>/<file>.cdx.json      — the file's SBOM (CycloneDX), and .spdx.json (SPDX)
    ├── maven/<group>/<artifact>/<version>/<file>
    ├── pypi/<name>/<version>/<file>
    ├── generic/<name>/<version>/<file>          — and the same shape for every other non-container type
    └── container/<image>/                        — one OCI image layout per image
        ├── oci-layout
        ├── index.json                            — one entry per tag
        └── blobs/sha256/<digest>                 — manifests, configs and layers

• Signerat tillsammans med paketet. Paketets manifest.json registrerar arkivets namn, storlek och SHA-256 (packages_archive) och varje fil i det (objects), så en och samma DSSE-signatur täcker båda nedladdningarna. VERIFY.md i paketet innehåller kommandona; se även §“Verifiera paketet”.
• SBOM:er. Varje paketfil levereras med den Software Bill of Materials som fremforge tog fram för den vid uppladdningen: <file>.cdx.json (CycloneDX) och, där en sådan togs fram, <file>.spdx.json (SPDX), bredvid filen, för alla typer utom containrar. De finns i manifestets objects precis som alla andra filer. En fil som skannern inte kunde bearbeta har ingen. Om ett paket självt levererar en fil med exakt det namnet behålls paketets fil och SBOM:en utelämnas. Container-images får inga SBOM:er per fil här; deras SBOM:er beskrivs under SBOM:er.
• Containrar är OCI image layouts, som skopeo, crane, oras och podman läser direkt. Så här pushar du till exempel en tagg till ett annat register: skopeo copy oci:packages/container/<image>:<tag> docker://<registry>/<image>:<tag>.
• Vanlig .tar, inte komprimerad: paketfiler (.tgz, wheels, jar-filer, image-lager) är redan komprimerade.
• Nedladdningslänk: visas som Paketinnehåll bredvid paketets länk och returneras av API:t som packages_signed_url. Giltig i 7 dagar, precis som paketets. Själva arkivet raderas efter 7 dagar; starta en ny export om du behöver det igen.
• Gräns på 50 GiB. Om din organisations paketinnehåll överstiger 50 GiB avvisas begäran direkt (export-too-large) och exporten utan paketinnehåll är fortfarande tillgänglig. Kontakta support@frem.sh för en assisterad export av större register.

Varje fil kontrolleras mot inventeringens storlek och SHA-256 när den skrivs, och varje SBOM mot den storlek och SHA-256 som registrerades när den togs fram; en export vars paketfiler inte stämmer misslyckas hellre än att leverera ett arkiv som motsäger sitt manifest.

Skanningsfynd, policy, attesteringar och SBOM:er

Varje export innehåller också den säkerhetsdata som fremforge har om din organisation, täckt av det signerade manifestet precis som alla andra filer:

• findings/: fynden från varje skanner, en NDJSON-fil per skanner (statisk analys, beroenden, licenser, container-images, secrets, skadlig kod i uppladdningar, beroenden och container-lager, sårbarheter och licenser i registrets paket, ofixerade actions i arbetsflöden), med sina avfärdanden: vem som avfärdade ett fynd, varför och till när.
• policy/: din paketpolicy, dess regler för tillåt och neka och dess godkännare, den aktuella bedömningen för varje paketfil, grindbeslut (inklusive dem som skuggläget skulle ha blockerat), undantag med sina godkännanden, åsidosättningar för skadlig kod och varje skanners organisationsinställningar.
• attestations/: din byggproveniens, dina release-attesteringar och attesteringar som laddats upp med en SBOM, var och en med sitt DSSE-kuvert och, där ett sådant togs fram, sitt nyckelfria Sigstore-paket.
• sboms/: varje SBOM som fremforge lagrar för dina repon (sboms/repos/, CycloneDX och, där en sådan togs fram, SPDX) och dina container-images (sboms/images/), som själva dokumenten, indexerade i sboms/index.ndjson. Varje rad i indexet anger om dokumentet stämde med den SHA-256 som registrerades när det lagrades. SBOM:er för paket finns inte här: de ligger bredvid sina filer i arkivet med paketinnehåll.

Filerna och deras fält listas i Exportschema.

Vad paketet INTE innehåller (och varför)

• Paketinnehåll och lager i container-images, om du inte begär dem: då kommer de som ett separat arkiv, se §“Paketinnehåll”.
• Innehåll i LFS-filer, se §“LFS-innehåll”.
• Release-tillgångar: releases.ndjson innehåller metadata för varje release, inklusive nedladdnings-URL:en för varje tillgång; hämta tillgångarna från de URL:erna.
• Loggar och körningsartefakter från Forgejo Actions exporteras inte. Ladda ner en körnings loggar och artefakter från körningens sida eller via Actions-API:t medan du behöver dem.
• SBOM:er för paket, om du inte begär paketinnehåll: SBOM:en för varje paketfil i registret följer med filen i arkivet med paketinnehåll. SBOM:er för repon och container-images finns i paketet, under sboms/ (se §“Skanningsfynd, policy, attesteringar och SBOM:er”).
• Fakturor och faktureringsposter ingår inte i paketet; de finns i administrationsgränssnittet under Fakturering.
• Andra tenants data: utdraget ur granskningsloggen innehåller bara din egen organisations granskningshändelser.

Så startar du en export

1. Organisationens administrationsgränssnitt → fliken Dataexport.
2. Kryssa eventuellt i Ta med paketinnehåll (se §“Paketinnehåll”).
3. Klicka på Starta en ny export.
4. Exportrunnern plockar upp jobbet inom 5 minuter. En liten organisation är klar några minuter senare; tiden växer med storleken på dina repon. Fliken Dataexport visar jobbets status och, när det är klart, nedladdningslänken.
5. Nedladdningslänken är giltig i 7 dagar efter att paketet blivit klart, och paketfilen raderas 7 dagar efter att den skapades, inklusive dess kopia för katastrofåterställning. Under en legal hold behålls filen.

Om en export misslyckas får den som begärde den ett mejl med orsaken, och du kan starta en ny direkt.

Begränsning av frekvens

En export per organisation per 24 timmar. Ett hårt tak. En misslyckad export räknas inte, så du kan försöka igen direkt. Orsaken: att köra git bundle på ett repo på flera GB och räkna fram manifestets hashar är inte gratis, och ett felklick ska inte starta hundra exporter under natten.

Om du verkligen behöver en andra export inom 24 timmar, kontakta support@frem.sh. Vi kan lyfta taket på begäran.

Storleksgränser

Arkivet strömmas till lagringen medan det byggs, så dess storlek begränsas inte av minnet eller av ett tak för en enskild uppladdning. Det som i dag begränsar en export:

• Ungefär 10 GB repo-bundles och metadata, det arbetsutrymme där exportrunnern mellanlagrar filer innan de arkiveras.
• En timme för hela exporten.
• 50 GiB paketinnehåll, när du begär det; avvisas redan vid begäran, se §“Paketinnehåll”.

En organisation över någon av gränserna får ett fel i stället för ett ofullständigt paket. Kontakta support@frem.sh så kör vi en assisterad export i stället (oftast en direkt synkronisering till din egen bucket).

För de flesta organisationer är repo-innehållet den överlägset största delen; metadata och granskningsdata är små i jämförelse.

Verifiera paketet

Att kontrollera att varje fil kom fram oskadd kräver en enda körning av sha256sum. Förutsättning: jq (SHA-256-verktyget följer med varje modernt operativsystem: sha256sum på Linux, shasum -a 256 på macOS).

Packa upp arkivet och kör sedan, i den uppackade katalogen:

# Linux
sha256sum --check <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

# macOS
shasum -a 256 -c <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

Om varje rad visar OK stämmer varje fil i paketet med den SHA-256-hash som fremforge registrerade. En avkortad eller skadad nedladdning går inte att packa upp ordentligt, eller underkänns i den här kontrollen.

Vad det här fångar och vad det inte fångar

SHA-256-kontrollen fångar manipulering efter exporten (skadad nedladdning, MITM-ändring av en osignerad spegel) och matchar paketet mot det manifest som fremforge tog fram. För att bevisa att själva manifestet togs fram av fremforge (och inte av en tredje part som bytt ut ditt paket mot sitt eget) kör du verifieringen av det signerade manifestet i nästa avsnitt; den binder kryptografiskt manifestets byte till fremforges publicerade Ed25519-byggnyckel.

Verifiera det signerade manifestet

Paketet levereras med ett DSSE-signerat in-toto Statement över manifest.json i manifest.json.intoto.jsonl. Signaturen görs med fremforges SLSA-byggnyckel (Ed25519), samma nyckel som signerar SLSA-byggproveniens för artefakter som den hostade runnern tar fram, och verifieras mot den publika förtroenderoten på https://www.frem.sh/.well-known/slsa-trust-root.json. Den aktiva nyckeln är fremforge-slsa-builder-v2, i bruk sedan nyckelbytet 2026-09-12; kommandona nedan väljer den. VERIFY.md i ditt paket innehåller samma kommandon med den nyckel som signerade just det paketet ifylld.

Använd den nyckel som kuvertet anger. keyid i manifest.json.intoto.jsonl (jq -r '.signatures[0].keyid' manifest.json.intoto.jsonl) är den nyckel som signerade det. Ett paket som exporterades före 2026-09-12 är signerat med fremforge-slsa-builder-v1, som finns kvar i förtroenderoten för att verifiera gamla signaturer (den signerar inte längre något); för ett sådant paket väljer du fremforge-slsa-builder-v1 i steg 1. Ett aktuellt paket verifieras inte under v1: steg 2 skriver då ut DSSE signature verification FAILED.

Du verifierar med curl, jq, openssl och python3, som alla ingår som standard i distributionerna. Inget fremforge-CLI. Inget beroende av Sigstore Fulcio / Rekor / TUF-CDN.

1. Hämta den publika förtroenderoten och plocka ut den publika nyckeln

curl -sSfL https://www.frem.sh/.well-known/slsa-trust-root.json -o trust-root.json
jq -r '.trusted_keys[] | select(.kid=="fremforge-slsa-builder-v2") | .pem' \
  trust-root.json > builder.pub

2. Verifiera DSSE-kuvertets signatur

python3 - <<'PY'
import base64, json, hashlib, subprocess, sys, pathlib

env = json.loads(pathlib.Path("manifest.json.intoto.jsonl").read_text().strip())
payload_type = env["payloadType"]
payload_b64  = env["payload"]
payload      = base64.b64decode(payload_b64)

# Reconstruct the DSSE pre-authentication encoding.
pae = (
    b"DSSEv1 "
    + str(len(payload_type)).encode() + b" "
    + payload_type.encode() + b" "
    + str(len(payload)).encode() + b" "
    + payload
)
pathlib.Path("pae.bin").write_bytes(pae)

sig_b64 = env["signatures"][0]["sig"]
pathlib.Path("sig.bin").write_bytes(base64.b64decode(sig_b64))

# Ed25519 verify with openssl: pkeyutl -verify needs the SAME bytes
# the signer hashed. EdDSA is "pure" — no pre-hash — so feed the
# raw PAE buffer.
r = subprocess.run(
    ["openssl", "pkeyutl", "-verify", "-pubin",
     "-inkey", "builder.pub",
     "-rawin", "-in", "pae.bin",
     "-sigfile", "sig.bin"],
    capture_output=True, text=True,
)
if r.returncode != 0 or "Signature Verified Successfully" not in r.stdout:
    print("DSSE signature verification FAILED:", r.stdout, r.stderr, file=sys.stderr)
    sys.exit(1)
print("DSSE signature: OK")

# Cross-check the signed manifestSha256 matches the on-disk manifest.json.
stmt = json.loads(payload)
claimed = stmt["predicate"]["manifestSha256"]
actual  = hashlib.sha256(pathlib.Path("manifest.json").read_bytes()).hexdigest()
if claimed != actual:
    print(f"manifestSha256 mismatch: signed={claimed} actual={actual}", file=sys.stderr)
    sys.exit(1)
print(f"manifestSha256: OK ({actual})")

# Sanity-check the predicate type.
if stmt["predicateType"] != "https://fremforge.eu/spec/export-bundle/v1":
    print(f"unexpected predicateType: {stmt['predicateType']}", file=sys.stderr)
    sys.exit(1)
print("predicateType: OK")
PY

3. Verifiera varje fils SHA-256 mot det (nu betrodda) manifestet

# Linux:
sha256sum --check <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

# macOS:
shasum -a 256 -c <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

Om alla tre stegen går igenom är paketet manipuleringsevident hela vägen: varje fil stämmer med den SHA-256 som fremforge registrerade, manifestet stämmer med det som fremforge signerade, och signaturen gjordes med den publicerade byggnyckeln.

4. Paketinnehåll (bara om du begärde det)

Ladda ner .packages.tar till samma katalog och kontrollera sedan arkivet och varje fil i det mot samma signerade manifest:

echo "$(jq -r '.packages_archive.sha256' manifest.json)  $(jq -r '.packages_archive.name' manifest.json)" | sha256sum --check
tar -xf "$(jq -r '.packages_archive.name' manifest.json)"
sha256sum --check <(jq -r '.objects[] | "\(.sha256)  \(.path)"' manifest.json)

Vad signaturen bevisar

• De byte i paketet som du fick är byte-identiska med det som fremforge tog fram vid exporten.
• Manifestet togs fram med fremforges byggnyckel, inte av en tredje part.
• Det signerade predikatet (https://fremforge.eu/spec/export-bundle/v1) anger organisationens slug, exportbegärans id, antal filer och totalt antal byte, så ett utbytt paket från en annan tenant skulle inte verifieras.

Vad den inte bevisar

• Tidpunkt: det signerade exportedAt intygas av fremforge; för tidsstämplar som en tredje part kan bevittna jämför du paketets utdrag ur granskningsloggen med den publika, WORM-förankrade granskningskedjan.
• Återkallade nycklar: förtroenderotens JSON är sanningskällan; om fremforge senare återkallar byggnyckeln slutar gamla signaturer att verifieras när nyckeln försvinner från trusted_keys. Hämta förtroenderoten på nytt om du verifierar långt efter att exporten utfärdades.

Klona om ett repo från ett bundle

Varje bundles/<repo>.bundle är ett vanligt git bundle. Så här återställer du:

git clone bundles/<repo>.bundle <repo>
cd <repo>
git remote remove origin                  # bundle URL is local
git remote add origin <new-fremforge-or-elsewhere-url>
git push -u --mirror origin

--mirror bevarar alla brancher, taggar och refs. Bundlet återskapar repots fullständiga historik med identiska SHA:er, och ingen force-push behövs till någon ny remote.

LFS-innehåll

Innehållet i LFS-filer finns inte i paketet. Git-bundlet innehåller varje LFS-fils pekare (dess oid och size), så historiken är komplett; själva innehållet ligger kvar på fremforges LFS-server. Att dra in många gigabyte binära bilagor i varje export skulle blåsa upp storleken för alla.

metadata/<repo>/lfs-manifest.ndjson är LFS-inventeringen per repo: en rad per LFS-objekt som någon branch, tagg eller pull request i repot hänvisar till.

Inventeringen byggs från repots historik, så objekt som laddats upp till LFS-servern men som ingen branch, tagg eller pull request hänvisar till listas inte. Ett repo utan LFS får en tom fil. Om repots historik hänvisar till LFS-objekt men fremforges LFS-server inte går att fråga misslyckas exporten hellre än att leverera en ofullständig inventering.

För att ladda ner LFS-innehållet, efter att du klonat om repot från bundlet:

git lfs install
git lfs fetch --all

Det hämtar från fremforges LFS-server medan du fortfarande är betalande kund (LFS-bandbredd ingår). Efter uppsägning behåller vi dina data i 90 dagar; LFS-hämtningar fungerar under den perioden.

För en enterprise-export som innehåller LFS-byte direkt i paketet, kontakta supporten. Vi dimensionerar paketet och kan behöva köra exporten som en synkronisering från OBS till OBS i stället för ett nedladdningsbart arkiv.

Byta till en annan leverantör (EU:s dataakt)

Det här avsnittet är den information som krävs enligt artikel 26 i EU:s dataakt (förordning (EU) 2023/2854). Avtalsvillkoren bakom det finns i villkoren §16.6.

Du kan byta till en annan leverantör, flytta allt till din egen infrastruktur eller få allt raderat, när som helst, med eller utan uppsägning.

Format. Allt i paketet är i öppna standardformat (git bundle, JSONL, in-toto DSSE, JSON), beskrivna på sidan Exportschema. Inget fremforge-proprietärt format, och inga fremforge-verktyg behövs för att läsa något av det.

Import till en egenhostad Forgejo. fremforge kör en modifierad Forgejo-build, men patchserien ändrar inte Forgejos datamodell, så en export kan importeras direkt till en egenhostad standardinstans av Forgejo. Klona om varje repo från dess bundle (§“Klona om ett repo från ett bundle”) och pusha till den nya värden med --mirror. Issues och pull requests flyttas via de GitHub-API-kompatibla endpoints som nämns nedan.

Radering i stället. Om du vill att data försvinner i stället för att flyttas, säg det i samma begäran. Vi raderar alla exporterbara data och digitala tillgångar enligt DPA §9 och bekräftar skriftligt.

Hjälp ingår. Enligt villkoren §16.6(h) bistår vi bytet i god tro, inklusive att besvara tekniska frågor från den leverantör du flyttar till. Fråga.

Uppsägning och exporten

Om du säger upp ditt fremforge-abonnemang:

• Ditt senaste exportfönster på 7 dagar förblir giltigt. Den signerade URL:en fortsätter att fungera.
• En ny export kan startas när som helst under den skrivskyddade lagringsperioden på 90 dagar efter uppsägningen. Samma flöde, samma gränssnitt, samma paket.
• En export som köas sent under perioden på 90 dagar, även vid +89 d 23 h, genomförs: fremforge skjuter upp den fysiska raderingen av din Forgejo-organisation i upp till 7 dagar efter 90-dagarsgränsen så länge en export står i kö eller körs. När exporten är klar fortsätter raderingen vid nästa schemalagda genomgång.
• Efter 90 dagar (plus exportens respitperiod ovan) rensas data enligt DPA §9; möjligheten att exportera upphör samtidigt.

Om du säger upp just för att du vill ha en sista export: gör exporten först, verifiera den lokalt och säg sedan upp. Fönstret är generöst, men verifiera-sedan-radera är det noggranna flödet.

Bara ett repo?

Den fullständiga exporten gäller hela organisationen: varje repo med sina issues, pull requests och releaser, paketinventeringen och utdraget ur granskningsloggen, i ett signerat paket. Om du bara behöver ett enda repo finns enklare vägar:

• git clone --mirror: fullständig Git-historik, brancher och taggar som ett bare-repo som kan klonas offline. fremforge exponerar inte port 22 publikt; använd antingen SSH-över-443-endpointen (ssh.frem.sh:443) eller HTTPS-formen:

  # SSH over port 443 (single endpoint for all orgs; uses your registered SSH key):
  git clone --mirror ssh://git@ssh.frem.sh:443/<org>/<repo>.git
  
  # OR HTTPS clone with a PAT (`ffp_…`) from Settings → API tokens:
  git clone --mirror "https://x-access-token:${FREMFORGE_PAT}@frem.sh/<org>/<repo>.git"
  
  cd <repo>.git
  git lfs fetch --all   # if the repo uses LFS

  Fingeravtrycken för värdnycklarna till ssh.frem.sh publiceras på www.frem.sh/ssh-fingerprints; verifiera dem vid första anslutningen. Resultatet är en katalog som är redo för git bundle; kör tar -czf på den för att få en portabel enskild fil.

• Ladda ner repot som zip/tarball: frem.sh/<org>/<repo>/archive/<branch>.zip eller .tar.gz ger en ögonblicksbild av en enda ref. Ingen historik, ingen LFS, bara arbetsträdet för den branchen.

• Issues + PR:er per repo som JSON, via API:t: GET /api/v1/repos/<org>/<repo>/issues?state=all&type=issues och ?type=pulls. Migreringsguiderna visar hur anropen ser ut; svaret är GitHub-API-kompatibel JSON.

Den signerade exporten för hela organisationen är rätt verktyg när du vill ha allt (varje repo, dess metadata, utdraget ur granskningsloggen, det signerade manifestet); vägarna per repo ovan passar det vardagliga fallet “jag måste skicka just det här repot till någon”.

Programmatiskt API

Samma export nås via REST-API:t:

# Start a new export
curl -X POST \
  -H "Authorization: Bearer <your-PAT>" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports

# ... or with package contents (separate archive, 50 GiB limit)
curl -X POST \
  -H "Authorization: Bearer <your-PAT>" -H "Content-Type: application/json" \
  -d '{"include_packages": true}' \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports

# Poll for status
curl -H "Authorization: Bearer <your-PAT>" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports/<job-id>

# When status=ready, follow the signed_url field
# (and packages_signed_url, if you asked for package contents)

OpenAPI-specifikation: docs.frem.sh/reference/api/.

Integritetsgarantier

Exporten är granskningsbar åt båda hållen:

• Vem som exporterade: varje exportbegäran registreras i din egen granskningslogg (data-export.requested från administrationsgränssnittet, data-export.queue.api från API:t) med användaren eller token som begärde den. Åtgärder som fremverks support vidtar i din organisation märks som sådana i samma logg.
• Vems data: utdraget ur granskningsloggen väljs ut efter din organisations tenant-id, så det innehåller bara din egen organisations granskningshändelser.
• Hygien för signerade URL:er: nedladdnings-URL:en är en försignerad, skrivskyddad länk till just ditt arkiv, giltig i 7 dagar. Därefter slutar URL:en att fungera och exporten försvinner från fliken Dataexport.

Korsreferenser

• Priser: ingår i planen för 30 €/användare; ingen separat nivå.
• DPA §9: åtagandet om återlämning av data som detta uppfyller.
• Förtroende: hur detta passar in i den bredare berättelsen om suveränitet och kontroll.