Fuld dataeksport

Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.

Du kan eksportere din organisations data, når du vil, fra administrationen: hvert repository som et git bundle, issues, pull requests, kommentarer, labels, milestones og releases for hvert repository, din pakkeoversigt, dine scanningsfund og afgørelser fra pakkepolitikken, dine build- og release-attestationer med deres signaturer, SBOM’erne for dine repositories og container-images samt revisionssporet for de seneste 90 dage. Alt er i standardformater og kan hentes som én .tar.gz med et signeret SHA-256-manifest, der dækker hver fil.

Denne side beskriver, hvad bundtet indeholder, hvordan du verificerer det, og hvilke grænser der gælder. Eksporten er inkluderet i planen til 30 € pr. plads; du behøver ikke et Enterprise-niveau.

Hvad bundtet indeholder

Bundtets struktur, hver fil i det og formen på hver post er beskrevet på én side: Eksportskema. Kort fortalt: et git bundle pr. repository; issues, pull requests, kommentarer, labels, milestones, releases og indstillinger for hvert repository som NDJSON; din pakkeoversigt og fillisten; din oversigt over tredjepartskomponenter; din adgangslog for registry’et; dine scanningsfund, afgørelser fra pakkepolitikken og signerede attestationer; SBOM’erne for dine repositories og container-images; og dit revisionsspor. Det hele ligger under ét DSSE-signeret SHA-256-manifest. Pakkeindhold leveres på anmodning som et separat arkiv, se §“Pakkeindhold”.

Pakkeindhold

Sæt hak i Medtag pakkeindhold, når du starter en eksport (eller send {"include_packages": true} til API’et), så laver eksporten et ekstra arkiv ved siden af bundtet: hver fil i hver pakkeversion, din organisation ejer, læst fra registry’ets lager på eksporttidspunktet.

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

• Signeret sammen med bundtet. Bundtets manifest.json registrerer arkivets navn, størrelse og SHA-256 (packages_archive) og hver fil i det (objects), så den ene DSSE-signatur dækker begge downloads. VERIFY.md i bundtet indeholder kommandoerne; se også §“Verificér bundtet”.
• SBOM’er. Hver pakkefil leveres med den software bill of materials, fremforge lavede for den, da den blev uploadet: <file>.cdx.json (CycloneDX) og, hvor der blev lavet en, <file>.spdx.json (SPDX), lige ved siden af filen, for alle typer undtagen containere. De står i manifestets objects som alle andre filer. En fil, scanneren ikke kunne behandle, har ingen. Hvis en pakke selv indeholder en fil med præcis det navn, beholdes pakkens fil, og SBOM’en udelades. Container-images får ikke SBOM’er pr. fil her; deres SBOM’er er beskrevet under SBOMs.
• Containere er OCI image layouts, som skopeo, crane, oras og podman kan læse direkte. Sådan pusher du for eksempel et tag til et andet registry: skopeo copy oci:packages/container/<image>:<tag> docker://<registry>/<image>:<tag>.
• Almindelig .tar, ikke komprimeret: pakkefiler (.tgz, wheels, jars, image-lag) er allerede komprimerede.
• Downloadlink: vises som Pakkeindhold ved siden af bundtets link og returneres af API’et som packages_signed_url. Gyldigt i 7 dage, ligesom bundtets. Selve arkivet slettes efter 8 dage; start en ny eksport, hvis du får brug for det igen.
• Grænse på 50 GiB. Hvis din organisations pakkeindhold overstiger 50 GiB, afvises anmodningen med det samme (export-too-large), og eksporten uden pakkeindhold er stadig tilgængelig. Kontakt support@frem.sh for en assisteret eksport af større registries.

Hver fil kontrolleres mod oversigtens størrelse og SHA-256, mens den skrives, og hver SBOM mod den størrelse og SHA-256, der blev registreret, da den blev lavet. En eksport, hvis pakkefiler ikke stemmer, fejler i stedet for at levere et arkiv, der er uenigt med sit manifest.

Scanningsfund, politik, attestationer og SBOM’er

Hver eksport indeholder også de sikkerhedsdata, fremforge har om din organisation, dækket af det signerede manifest som alle andre filer:

• findings/: fundene fra hver scanner, én NDJSON-fil for hver (statisk analyse, afhængigheder, licenser, container-images, hemmeligheder, malware i uploads, afhængigheder og container-lag, sårbarheder og licenser i registry-pakker, workflow-actions uden pinning), med deres afvisninger: hvem der afviste et fund, hvorfor og indtil hvornår.
• policy/: din pakkepolitik, dens allow- og deny-regler og godkendere, den aktuelle afgørelse for hver pakkefil, gate-afgørelser (også dem, shadow mode ville have blokeret), undtagelser med deres godkendelser, malware-overrides og hver scanners organisationsindstillinger.
• attestations/: din build provenance, release-attestationer og attestationer uploadet sammen med en SBOM, hver med sin DSSE-envelope og, hvor der blev lavet et, sit nøgleløse Sigstore-bundle.
• sboms/: hver SBOM, fremforge gemmer for dine repositories (sboms/repos/, CycloneDX og, hvor der blev lavet en, SPDX) og dine container-images (sboms/images/), som selve dokumenterne, indekseret i sboms/index.ndjson. Hver linje i indekset angiver, om dokumentet matchede den SHA-256, der blev registreret, da det blev gemt. Pakke-SBOM’er ligger ikke her: de følger med deres filer i arkivet med pakkeindhold.

Filerne og deres felter er listet i Eksportskema.

Hvad bundtet IKKE indeholder (og hvorfor)

• Pakkeindhold og lag fra container-images, medmindre du beder om dem: så kommer de som et separat arkiv, se §“Pakkeindhold”.
• Indhold af LFS-filer, se §“LFS-indhold”.
• Release assets: releases.ndjson indeholder metadata for hver release, herunder download-URL’en for hvert asset; hent dine assets fra de URL’er.
• Logs og run artifacts fra Forgejo Actions eksporteres ikke. Hent et runs logs og artifacts fra run-siden eller via Actions API’et, mens du har brug for dem.
• Pakke-SBOM’er, medmindre du beder om pakkeindhold: SBOM’en for hver pakkefil i registry’et følger med filen i arkivet med pakkeindhold. SBOM’er for repositories og container-images er med i bundtet, under sboms/ (se §“Scanningsfund, politik, attestationer og SBOM’er”).
• Fakturaer og faktureringsdata er ikke en del af bundtet; de ligger i administrationen under Fakturering.
• Andre tenants’ data: udsnittet af revisionsloggen indeholder kun din egen organisations hændelser.

Sådan starter du en eksport

1. Organisationsadministrationen → fanen Dataeksport.
2. Sæt eventuelt hak i Medtag pakkeindhold (se §“Pakkeindhold”).
3. Klik på Start en ny eksport.
4. Eksportjobbet bliver samlet op inden for 5 minutter. En lille organisation er klar et par minutter senere; tiden vokser med størrelsen på dine repositories. Fanen Dataeksport viser jobbets status og, når det er klar, downloadlinket.
5. Downloadlinket er gyldigt i 7 dage, efter bundtet er klar.

Hvis en eksport fejler, får den person, der bestilte den, en e-mail med årsagen, og du kan starte en ny med det samme.

Begrænsning på antal eksporter

Én eksport pr. organisation pr. 24 timer. Det er en fast grænse. En fejlet eksport tæller ikke med, så du kan prøve igen med det samme. Begrundelsen: at køre git bundle på et repository på flere GB og beregne manifest-hashes er ikke gratis, og et fejlklik skal ikke kunne starte hundrede eksporter i løbet af natten.

Hvis du reelt har brug for endnu en eksport inden for 24 timer, så kontakt support@frem.sh. Vi kan ophæve grænsen efter anmodning.

Størrelsesgrænser

Arkivet streames til lageret, mens det bygges, så størrelsen er ikke begrænset af hukommelse eller af en grænse for enkelt-uploads. Det, der i dag sætter grænsen for en eksport, er:

• Ca. 10 GB repository-bundles og metadata: det arbejdsområde, eksportjobbet lægger filerne i, før de arkiveres.
• Én time for hele eksporten.
• 50 GiB pakkeindhold, når du beder om det; afvises allerede ved anmodningen, se §“Pakkeindhold”.

En organisation over en af grænserne får en fejl i stedet for et ufuldstændigt bundt. Kontakt support@frem.sh, så kører vi i stedet en assisteret eksport (typisk en direkte synkronisering til din egen bucket).

For de fleste organisationer er repository-indholdet langt den største del; metadata og revisionsdata fylder lidt til sammenligning.

Verificér bundtet

Det kræver én kørsel af sha256sum at tjekke, at hver fil er nået intakt frem. Forudsætning: jq (SHA-256-værktøjet følger med ethvert moderne styresystem: sha256sum på Linux, shasum -a 256 på macOS).

Pak arkivet ud, og kør derefter i den udpakkede mappe:

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

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

Hvis hver linje melder OK, matcher hver fil i bundtet den SHA-256-hash, fremforge registrerede. En afkortet eller beskadiget download kan ikke pakkes rent ud eller fejler dette tjek.

Hvad tjekket fanger, og hvad det ikke fanger

SHA-256-tjekket fanger manipulation efter eksporten (beskadigede downloads, MITM-ændringer via et usigneret mirror) og knytter bundtet til det manifest, fremforge lavede. For at bevise, at selve manifestet er lavet af fremforge (og ikke af en tredjepart, der har byttet dit bundt ud med sit eget), skal du køre verifikationen af det signerede manifest i næste afsnit. Den binder kryptografisk manifestets bytes til fremforges offentliggjorte Ed25519-builder-nøgle.

Verificér det signerede manifest

Bundtet indeholder et DSSE-signeret in-toto Statement over manifest.json i manifest.json.intoto.jsonl. Signaturen laves med fremforges SLSA-builder-nøgle (Ed25519), den samme nøgle, som signerer SLSA build provenance for artifacts bygget på den hostede runner, og den verificeres mod den offentlige trust root på https://www.frem.sh/.well-known/slsa-trust-root.json. Den aktive nøgle er fremforge-slsa-builder-v2, som har været i brug siden nøgleskiftet 12. september 2026; kommandoerne nedenfor vælger den. VERIFY.md i dit bundt indeholder de samme kommandoer, udfyldt med den nøgle, der signerede netop det bundt.

Brug den nøgle, envelopen angiver. keyid i manifest.json.intoto.jsonl (jq -r '.signatures[0].keyid' manifest.json.intoto.jsonl) er den nøgle, der signerede den. Et bundt eksporteret før 12. september 2026 er signeret med fremforge-slsa-builder-v1, som bliver i trust root’en, så gamle signaturer kan verificeres (den signerer ikke længere noget); for sådan et bundt vælger du fremforge-slsa-builder-v1 i trin 1. Et aktuelt bundt verificerer ikke med v1: trin 2 skriver så DSSE signature verification FAILED.

Du verificerer med curl, jq, openssl og python3, som alle følger med distributionerne som standard. Intet fremforge-CLI. Ingen afhængighed af Sigstore Fulcio / Rekor / TUF-CDN.

1. Hent den offentlige trust root, og udtræk den offentlige nøgle

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. Verificér signaturen på DSSE-envelopen

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. Verificér hver fils SHA-256 mod det (nu betroede) manifest

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

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

Hvis alle tre trin går igennem, er bundtet manipulationssikret fra ende til anden: hver fil matcher den SHA-256, fremforge registrerede, manifestet matcher det, fremforge signerede, og signaturen er lavet med den offentliggjorte builder-nøgle.

4. Pakkeindhold (kun hvis du bad om det)

Hent .packages.tar ned i samme mappe, og tjek derefter arkivet og hver fil i det mod det samme signerede 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)

Hvad signaturen beviser

• De bytes, du har modtaget, er identiske med dem, fremforge lavede på eksporttidspunktet.
• Manifestet er lavet med fremforges builder-nøgle og ikke af en tredjepart.
• Det signerede predicate (https://fremforge.eu/spec/export-bundle/v1) angiver organisationens slug, eksportanmodningens id, antallet af filer og det samlede antal bytes, så et bundt fra en anden tenant, der er byttet ind, ville ikke kunne verificeres.

Hvad den ikke beviser

• Tidspunktet: det signerede exportedAt er fremforges egen angivelse. Har du brug for tidsstempler, som en tredjepart kan bevidne, så sammenhold bundtets udsnit af revisionsloggen med den offentlige, WORM-forankrede audit chain.
• Tilbagekaldelse af nøglen: trust root-JSON’en er sandhedskilden. Hvis fremforge senere tilbagekalder builder-nøglen, holder gamle signaturer op med at verificere, når nøglen forsvinder fra trusted_keys. Hent trust root’en igen, hvis du verificerer lang tid efter, at eksporten blev lavet.

Klon et repository igen fra et bundle

Hver bundles/<repo>.bundle er et almindeligt git bundle. Sådan gendanner 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 bevarer alle branches, tags og refs. Bundtet genskaber hele repository-historikken med identiske SHA’er, så der kræves ingen force-push til et nyt remote.

LFS-indhold

Indholdet af LFS-filer er ikke med i bundtet. Git-bundtet indeholder hver LFS-fils pointer (dens oid og size), så historikken er komplet; selve indholdet bliver på fremforges LFS-server. Hvis mange gigabyte binære vedhæftninger skulle med i hver eksport, ville størrelsen eksplodere for alle.

metadata/<repo>/lfs-manifest.ndjson er LFS-oversigten pr. repository: én linje pr. LFS-objekt, som en branch, et tag eller en pull request i repository’et refererer til.

Oversigten bygges ud fra repository’ets historik, så objekter, der er uploadet til LFS-serveren, men som ingen branch, tag eller pull request refererer til, er ikke med. Et repository uden LFS får en tom fil. Hvis repository’ets historik refererer til LFS-objekter, men fremforges LFS-server ikke kan forespørges, fejler eksporten i stedet for at levere en ufuldstændig oversigt.

Når du har klonet repository’et fra bundtet, henter du LFS-indholdet sådan:

git lfs install
git lfs fetch --all

Det henter fra fremforges LFS-server, mens du stadig er betalende kunde (LFS-båndbredde er inkluderet). Efter en opsigelse beholder vi dine data i 90 dage; LFS-pulls virker i den periode.

Har du brug for en enterprise-eksport, hvor LFS-bytes er med direkte, så kontakt support. Vi vurderer størrelsen af bundtet og kan blive nødt til at køre eksporten som en OBS-til-OBS-synkronisering i stedet for et arkiv til download.

Skift til en anden udbyder (EU’s dataforordning)

Dette afsnit er den oplysning, som artikel 26 i EU’s dataforordning (forordning (EU) 2023/2854) kræver. De kontraktlige vilkår bag den står i ToS §16.6.

Du kan skifte til en anden udbyder, flytte det hele til din egen infrastruktur eller få det hele slettet — når som helst, med eller uden opsigelse.

Formater. Alt i bundtet er i åbne standardformater — git bundle, JSONL, in-toto DSSE, JSON — beskrevet på siden Eksportskema. Intet fremforge-proprietært format, og du behøver intet fremforge-værktøj for at læse noget af det.

Import i en selvhostet Forgejo. fremforge kører et modificeret Forgejo-build, men patch-serien ændrer ikke Forgejos datamodel, så en eksport kan importeres direkte i en almindelig selvhostet Forgejo-instans. Klon hvert repository fra sit bundle (§“Klon et repository igen fra et bundle”), og push til den nye vært med --mirror. Issues og pull requests flyttes via de GitHub-API-kompatible endpoints, der er nævnt nedenfor.

Sletning i stedet. Vil du have dataene slettet i stedet for flyttet, så skriv det i samme anmodning. Vi sletter alle data og digitale aktiver, der kan eksporteres, jf. DPA §9, og bekræfter det skriftligt.

Hjælp er en del af aftalen. Efter ToS §16.6(h) hjælper vi loyalt med skiftet — også ved at besvare tekniske spørgsmål fra den udbyder, du flytter til. Spørg bare.

Opsigelse og eksporten

Hvis du opsiger dit fremforge-abonnement:

• Dit seneste eksportvindue på 7 dage forbliver gyldigt. Den signerede URL virker stadig.
• Du kan starte en ny eksport når som helst i løbet af de 90 dage efter opsigelsen, hvor dataene opbevares skrivebeskyttet. Samme forløb, samme brugerflade, samme bundt.
• En eksport, der sættes i kø sent i perioden på 90 dage, selv efter 89 dage og 23 timer, bliver gennemført: fremforge udskyder den fysiske sletning af din Forgejo-organisation i op til 7 dage efter de 90 dage, når en eksport står i kø eller kører. Når eksporten er færdig, sker sletningen ved næste planlagte oprydning.
• Efter 90 dage (plus fristen for eksport ovenfor) bliver dataene slettet jf. DPA §9, og muligheden for eksport ophører samtidig.

Hvis du opsiger, netop fordi du vil have en sidste eksport, så lav eksporten først, verificér den lokalt, og opsig derefter. Vinduet er rummeligt, men verificér-og-slet er den grundige fremgangsmåde.

Kun ét repository?

Den fulde eksport omfatter hele organisationen: hvert repository med issues, pull requests og releases, pakkeoversigten og udsnittet af revisionsloggen, i ét signeret bundt. Har du kun brug for et enkelt repository, er disse veje enklere:

• git clone --mirror: fuld Git-historik, branches og tags som et bare repository, der kan klones offline. fremforge eksponerer ikke port 22 offentligt; brug enten SSH-over-443-endpointet (ssh.frem.sh:443) eller HTTPS:

  # 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

  Fingerprints for værtsnøglerne til ssh.frem.sh er offentliggjort på www.frem.sh/ssh-fingerprints; verificér dem ved første forbindelse. Resultatet er en mappe, der er klar til git bundle; kør tar -czf på den, hvis du vil have én fil, der er nem at flytte.

• Download af repository som zip/tarball: frem.sh/<org>/<repo>/archive/<branch>.zip eller .tar.gz giver et øjebliksbillede af én ref. Ingen historik, ingen LFS, kun arbejdstræet på den branch.

• Issues og pull requests som JSON pr. repository via API’et: GET /api/v1/repos/<org>/<repo>/issues?state=all&type=issues og ?type=pulls. Migreringsguiderne viser kaldets form; svaret er GitHub-API-kompatibel JSON.

Den signerede eksport af hele organisationen er det rette værktøj, når du vil have alt (hvert repository, dets metadata, udsnittet af revisionsloggen, det signerede manifest); vejene pr. repository ovenfor passer til hverdagssituationen “jeg skal sende lige det her ene repository til nogen”.

API til programmatisk brug

Den samme eksport kan nås via REST API’et:

# 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/.

Garantier for privatlivet

Eksporten kan revideres i begge retninger:

• Hvem der eksporterede: hver eksportanmodning registreres i din egen revisionslog (data-export.requested fra administrationen, data-export.queue.api fra API’et) med den bruger eller det token, der bad om den. Handlinger, som fremverks support udfører på din organisation, er markeret som sådan i samme log.
• Hvis data: udsnittet af revisionsloggen udvælges ud fra din organisations tenant-id, så det indeholder kun din egen organisations hændelser.
• Hygiejne for signerede URL’er: download-URL’en er et forhåndssigneret, skrivebeskyttet link til netop dit arkiv, gyldigt i 7 dage. Derefter virker URL’en ikke længere, og eksporten forsvinder fra fanen Dataeksport.

Krydsreferencer

• Priser: inkluderet i planen til 30 € pr. plads; ikke et separat niveau.
• DPA §9: forpligtelsen til at tilbagelevere data, som eksporten opfylder.
• Trust: hvordan dette passer ind i den samlede historie om suverænitet og kontrol.