Export complet des données

Vous pouvez exporter à la demande les données de votre organisation depuis l’interface d’administration : chaque dépôt sous forme de bundle git, les issues, pull requests, commentaires, labels, jalons et releases de chaque dépôt, votre inventaire de paquets, vos résultats d’analyse et décisions de la politique de paquets, vos attestations de build et de release avec leurs signatures, les SBOM de vos dépôts et de vos images de conteneur, et la piste d’audit des 90 derniers jours. Tout est dans un format standard, téléchargeable en un seul .tar.gz accompagné d’un manifeste SHA-256 signé qui couvre chaque fichier.

Cette page décrit le contenu du bundle, la manière de le vérifier et les limites qui s’appliquent. L’export est inclus dans la formule à 30 € par utilisateur ; aucune offre Enterprise n’est nécessaire.

Contenu du bundle

La structure du bundle, chacun de ses fichiers et la forme de chaque enregistrement sont décrits sur une seule page : Schéma de l’export. En bref : un bundle git par dépôt, les issues, pull requests, commentaires, labels, jalons, releases et paramètres de chaque dépôt en NDJSON, votre inventaire de paquets et la liste de leurs fichiers, votre inventaire de composants tiers, votre journal d’accès au registre, vos résultats d’analyse, les décisions de la politique de paquets et les attestations signées, les SBOM de vos dépôts et de vos images de conteneur, et votre piste d’audit, le tout sous un seul manifeste SHA-256 signé en DSSE. Le contenu des paquets est fourni sur demande dans une seconde archive, voir § « Contenu des paquets ».

Contenu des paquets

Cochez Inclure le contenu des paquets au lancement d’un export (ou envoyez {"include_packages": true} à l’API) et l’export produit une seconde archive à côté du bundle : chaque fichier de chaque version de paquet appartenant à votre organisation, lu dans le stockage du registre au moment de l’export.

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

• Signée avec le bundle. Le manifest.json du bundle enregistre le nom, la taille et le SHA-256 de l’archive (packages_archive) ainsi que chaque fichier qu’elle contient (objects), de sorte que l’unique signature DSSE couvre les deux téléchargements. Le fichier VERIFY.md du bundle contient les commandes ; voir aussi § « Vérifier le bundle ».
• SBOM. Chaque fichier de paquet est accompagné de la nomenclature logicielle que fremforge a produite lors de son envoi : <file>.cdx.json (CycloneDX) et, lorsqu’il en existe une, <file>.spdx.json (SPDX), à côté du fichier, pour tous les types autres que les conteneurs. Ils figurent dans les objects du manifeste comme tous les autres fichiers. Un fichier que l’analyseur n’a pas pu traiter n’en a pas. Si un paquet contient lui-même un fichier portant exactement ce nom, le fichier du paquet est conservé et la SBOM est omise. Les images de conteneur ne reçoivent pas ici de SBOM par fichier ; leurs SBOM sont décrites dans SBOM.
• Les conteneurs sont fournis au format OCI image layout, que skopeo, crane, oras et podman lisent directement. Par exemple, pour pousser un tag vers un autre registre : skopeo copy oci:packages/container/<image>:<tag> docker://<registry>/<image>:<tag>.
• Un .tar simple, non compressé : les fichiers des paquets (.tgz, wheels, jars, couches d’image) sont déjà compressés.
• Lien de téléchargement : affiché sous le nom Contenu des paquets à côté du lien du bundle, et renvoyé par l’API dans packages_signed_url. Valable 7 jours, comme celui du bundle. L’archive elle-même est supprimée après 7 jours ; lancez un nouvel export si vous en avez de nouveau besoin.
• Limite de 50 Gio. Si le contenu des paquets de votre organisation dépasse 50 Gio, la demande est refusée immédiatement (export-too-large) et l’export sans le contenu des paquets reste disponible. Contactez support@frem.sh pour un export assisté des registres plus volumineux.

Chaque fichier est contrôlé, au moment de son écriture, par rapport à la taille et au SHA-256 de l’inventaire, et chaque SBOM par rapport à la taille et au SHA-256 enregistrés lors de sa création ; un export dont les fichiers de paquets ne correspondent pas échoue plutôt que de livrer une archive en désaccord avec son manifeste.

Résultats d’analyse, politique, attestations et SBOM

Chaque export contient aussi les données de sécurité que fremforge détient sur votre organisation, couvertes par le manifeste signé comme tous les autres fichiers :

• findings/ : les résultats de chaque analyseur, un fichier NDJSON par analyseur (analyse statique, dépendances, licences, images de conteneur, secrets, logiciels malveillants dans les envois, les dépendances et les couches de conteneur, vulnérabilités et licences des paquets du registre, actions de workflow non épinglées), avec leurs rejets : qui a rejeté un résultat, pourquoi et jusqu’à quand.
• policy/ : votre politique de paquets, ses règles d’autorisation et de refus et ses approbateurs, le verdict actuel pour chaque fichier de paquet, les décisions de la barrière (y compris celles que le mode observation aurait bloquées), les exceptions avec leurs approbations, les dérogations pour logiciels malveillants et les paramètres d’organisation de chaque analyseur.
• attestations/ : la provenance de vos builds, les attestations de release et les attestations envoyées avec une SBOM, chacune avec son enveloppe DSSE et, lorsqu’il en existe un, son bundle Sigstore keyless.
• sboms/ : chaque SBOM que fremforge conserve pour vos dépôts (sboms/repos/, en CycloneDX et, lorsqu’il en existe une, en SPDX) et vos images de conteneur (sboms/images/), sous forme des documents eux-mêmes, indexés par sboms/index.ndjson. Chaque ligne de l’index indique si le document correspondait au SHA-256 enregistré lors de son stockage. Les SBOM des paquets ne sont pas ici : elles accompagnent leurs fichiers dans l’archive du contenu des paquets.

Les fichiers et leurs champs sont listés dans Schéma de l’export.

Ce qui n’est PAS dans le bundle (et pourquoi)

• Le contenu des paquets et les couches des images de conteneur, sauf si vous les demandez : ils arrivent alors dans une archive séparée, voir § « Contenu des paquets ».
• Le contenu des fichiers LFS, voir § « Contenu LFS ».
• Les assets de release : releases.ndjson contient les métadonnées de chaque release, dont l’URL de téléchargement de chaque asset ; récupérez les assets à partir de ces URL.
• Les journaux et artefacts d’exécution de Forgejo Actions ne sont pas exportés. Téléchargez les journaux et artefacts d’une exécution depuis la page de l’exécution ou via l’API Actions tant que vous en avez besoin.
• Les SBOM des paquets, sauf si vous demandez le contenu des paquets : la SBOM de chaque fichier de paquet du registre accompagne le fichier dans l’archive du contenu des paquets. Les SBOM des dépôts et des images de conteneur sont dans le bundle, sous sboms/ (voir § « Résultats d’analyse, politique, attestations et SBOM »).
• Les factures et données de facturation ne font pas partie du bundle ; elles se trouvent dans l’interface d’administration sous Facturation.
• Les données des autres organisations : la tranche du journal d’audit ne contient que les événements d’audit de votre propre organisation.

Lancer un export

1. Interface d’administration de l’organisation → onglet Export de données.
2. Cochez éventuellement Inclure le contenu des paquets (voir § « Contenu des paquets »).
3. Cliquez sur Lancer un nouvel export.
4. Le runner d’export prend en charge la tâche dans les 5 minutes. Une petite organisation est prête quelques minutes plus tard ; la durée augmente avec la taille de vos dépôts. L’onglet Export de données affiche le statut de la tâche et, une fois l’export prêt, le lien de téléchargement.
5. Le lien de téléchargement est valable 7 jours après que le bundle est prêt, et le fichier du bundle est supprimé 7 jours après sa création, y compris sa copie de reprise après sinistre. Sous conservation légale, le fichier est conservé.

Si un export échoue, la personne qui l’a demandé reçoit un e-mail indiquant la raison, et vous pouvez en lancer un nouveau immédiatement.

Limite de fréquence

Un export par organisation toutes les 24 heures. Plafond strict. Un export en échec ne compte pas, vous pouvez donc réessayer tout de suite. La raison : produire le git bundle d’un dépôt de plusieurs Go et calculer les empreintes du manifeste n’est pas gratuit, et un clic malheureux ne doit pas déclencher une centaine d’exports pendant la nuit.

Si vous avez réellement besoin d’un second export dans les 24 heures, contactez support@frem.sh. Nous pouvons lever le plafond sur demande.

Limites de taille

L’archive est envoyée en flux vers le stockage au fur et à mesure de sa construction ; sa taille n’est donc limitée ni par la mémoire ni par un plafond d’envoi unique. Ce qui borne un export aujourd’hui :

• Environ 10 Go de bundles de dépôts et de métadonnées, l’espace de travail dans lequel le runner d’export prépare les fichiers avant de les archiver.
• Une heure pour l’ensemble de l’export.
• 50 Gio de contenu de paquets, lorsque vous le demandez ; refusé au moment de la demande, voir § « Contenu des paquets ».

Une organisation qui dépasse l’une de ces limites obtient une erreur plutôt qu’un bundle partiel. Contactez support@frem.sh et nous réaliserons un export assisté (généralement une synchronisation directe vers votre propre bucket).

Pour la plupart des organisations, le contenu des dépôts représente de loin la plus grande part ; les métadonnées et les données d’audit sont faibles en comparaison.

Vérifier le bundle

Vérifier que chaque fichier vous est parvenu intact ne demande qu’une exécution de sha256sum. Prérequis : jq (l’utilitaire SHA-256 est fourni avec tout système d’exploitation récent : sha256sum sous Linux, shasum -a 256 sous macOS).

Décompressez l’archive, puis, dans le répertoire décompressé :

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

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

Si chaque ligne indique OK, chaque fichier du bundle correspond à l’empreinte SHA-256 enregistrée par fremforge. Un téléchargement tronqué ou corrompu ne se décompresse pas proprement, ou échoue à ce contrôle.

Ce que ce contrôle détecte et ce qu’il ne détecte pas

Le contrôle SHA-256 détecte toute altération postérieure à l’export (corruption du téléchargement, modification par un intermédiaire sur un miroir non signé) et rattache le bundle au manifeste produit par fremforge. Pour prouver que le manifeste lui-même a été produit par fremforge (et non par un tiers qui aurait remplacé votre bundle par le sien), effectuez la vérification du manifeste signé décrite dans la section suivante : elle lie cryptographiquement les octets du manifeste à la clé de builder Ed25519 publiée par fremforge.

Vérifier le manifeste signé

Le bundle contient, dans manifest.json.intoto.jsonl, un Statement in-toto signé en DSSE portant sur manifest.json. La signature est produite avec la clé Ed25519 du builder SLSA de fremforge, la même clé qui signe la provenance de build SLSA des artefacts produits par le runner hébergé, et se vérifie contre la racine de confiance publique publiée à https://www.frem.sh/.well-known/slsa-trust-root.json. La clé active est fremforge-slsa-builder-v2, en service depuis la rotation de clé du 12 septembre 2026 ; les commandes ci-dessous la sélectionnent. Le fichier VERIFY.md de votre bundle contient les mêmes commandes, avec la clé qui a signé ce bundle déjà renseignée.

Utilisez la clé que nomme l’enveloppe. Le keyid de manifest.json.intoto.jsonl (jq -r '.signatures[0].keyid' manifest.json.intoto.jsonl) est la clé qui l’a signé. Un bundle exporté avant le 12 septembre 2026 est signé avec fremforge-slsa-builder-v1, qui reste dans la racine de confiance pour vérifier les anciennes signatures (elle ne signe plus rien) ; pour un tel bundle, sélectionnez fremforge-slsa-builder-v1 à l’étape 1. Un bundle actuel ne se vérifie pas avec v1 : l’étape 2 affiche alors DSSE signature verification FAILED.

La vérification se fait avec curl, jq, openssl et python3, tous présents par défaut dans les distributions. Pas de CLI fremforge. Aucune dépendance à Sigstore Fulcio / Rekor / un CDN TUF.

1. Récupérer la racine de confiance publique et en extraire la clé publique

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. Vérifier la signature de l’enveloppe DSSE

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. Vérifier le SHA-256 de chaque fichier contre le manifeste (désormais de confiance)

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

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

Si les trois étapes réussissent, le bundle est inviolable de bout en bout : chaque fichier correspond au SHA-256 enregistré par fremforge, le manifeste correspond à ce que fremforge a signé, et la signature a été produite par la clé de builder publiée.

4. Contenu des paquets (uniquement si vous l’avez demandé)

Téléchargez le .packages.tar dans le même répertoire, puis vérifiez l’archive et chacun de ses fichiers contre le même manifeste signé :

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)

Ce que prouve la signature

• Les octets du bundle que vous avez reçus sont identiques, octet pour octet, à ce que fremforge a produit au moment de l’export.
• Le manifeste a été produit par la clé de builder de fremforge, et non par un tiers.
• Le prédicat signé (https://fremforge.eu/spec/export-bundle/v1) déclare le slug de l’organisation, l’identifiant de la demande d’export, le nombre de fichiers et le nombre total d’octets : la substitution du bundle d’une autre organisation ne se vérifierait pas.

Ce qu’elle ne prouve pas

• L’horodatage : le exportedAt signé est affirmé par fremforge ; pour des horodatages vérifiables par un tiers, rapprochez la tranche du journal d’audit du bundle de la chaîne d’audit publique ancrée en WORM.
• La révocation de clé : le JSON de la racine de confiance fait foi ; si fremforge révoque plus tard la clé de builder, les anciennes signatures cessent de se vérifier dès que la clé disparaît de trusted_keys. Récupérez de nouveau la racine de confiance si vous vérifiez longtemps après l’émission de l’export.

Recloner un dépôt à partir d’un bundle

Chaque bundles/<repo>.bundle est un git bundle standard. Pour le restaurer :

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 conserve toutes les branches, tous les tags et toutes les refs. Le bundle reconstitue l’historique complet du dépôt, avec des SHA identiques, sans aucun force-push vers le nouveau dépôt distant.

Contenu LFS

Le contenu des fichiers LFS n’est pas dans le bundle. Le bundle git contient le pointeur de chaque fichier LFS (son oid et sa size), l’historique est donc complet ; le contenu lui-même reste sur le serveur LFS de fremforge. Embarquer des gigaoctets de pièces jointes binaires dans chaque export en ferait exploser la taille pour tout le monde.

metadata/<repo>/lfs-manifest.ndjson est l’inventaire LFS du dépôt : une ligne par objet LFS référencé par une branche, un tag ou une pull request du dépôt.

L’inventaire est construit à partir de l’historique du dépôt ; les objets envoyés au serveur LFS mais référencés par aucune branche, aucun tag ni aucune pull request ne sont donc pas listés. Un dépôt sans LFS reçoit un fichier vide. Si l’historique du dépôt référence des objets LFS mais que le serveur LFS de fremforge ne peut pas être interrogé, l’export échoue plutôt que de livrer un inventaire incomplet.

Pour télécharger le contenu LFS, après avoir recloné le dépôt à partir du bundle :

git lfs install
git lfs fetch --all

Cette commande récupère les données depuis le serveur LFS de fremforge tant que vous êtes client payant (la bande passante LFS est incluse). Après une résiliation, nous conservons vos données pendant 90 jours ; les récupérations LFS fonctionnent pendant cette période.

Pour un export entreprise incluant directement les octets LFS, contactez le support. Nous dimensionnerons le bundle et devrons peut-être réaliser l’export sous forme de synchronisation OBS vers OBS plutôt que d’archive téléchargeable.

Changer de fournisseur (règlement européen sur les données)

Cette section constitue la notice d’information exigée par l’article 26 du règlement européen sur les données (Data Act, règlement (UE) 2023/2854). Les conditions contractuelles correspondantes figurent au §16.6 des CGU.

Vous pouvez passer à un autre fournisseur, tout transférer vers votre propre infrastructure ou tout faire effacer — à tout moment, avec ou sans résiliation.

Formats. Tout le contenu du bundle est dans un format ouvert standard — git bundle, JSONL, in-toto DSSE, JSON — décrit sur la page Schéma de l’export. Aucun format propriétaire fremforge, et aucun outil fremforge n’est nécessaire pour lire quoi que ce soit.

Import dans un Forgejo auto-hébergé. fremforge exécute une version modifiée de Forgejo, mais la série de correctifs ne modifie pas le modèle de données de Forgejo ; un export s’importe donc directement dans une instance Forgejo auto-hébergée standard. Reclonez chaque dépôt à partir de son bundle (§ « Recloner un dépôt à partir d’un bundle ») et poussez-le vers le nouvel hébergeur avec --mirror. Les issues et pull requests sont transférées via les points de terminaison compatibles avec l’API GitHub mentionnés plus bas.

Effacement plutôt que transfert. Si vous voulez que les données soient supprimées plutôt que déplacées, indiquez-le dans la même demande. Nous effaçons toutes les données exportables et tous les actifs numériques conformément au §9 du DPA et le confirmons par écrit.

L’aide fait partie de l’accord. Au titre du §16.6(h) des CGU, nous vous assistons de bonne foi dans le changement — y compris en répondant aux questions techniques du fournisseur vers lequel vous partez. Demandez.

Résiliation et export

Si vous résiliez votre abonnement fremforge :

• Votre dernière fenêtre d’export de 7 jours reste valable. L’URL signée continue de fonctionner.
• Un nouvel export peut être déclenché à tout moment pendant la période de conservation en lecture seule de 90 jours qui suit la résiliation. Même processus, même interface, même bundle.
• Un export mis en file tard dans la fenêtre de 90 jours, même à J+89 23 h, est honoré : fremforge suspend la suppression physique de votre organisation Forgejo jusqu’à 7 jours au-delà des 90 jours dès qu’un export est en file ou en cours. Une fois l’export terminé, la suppression a lieu lors du prochain passage planifié.
• Après 90 jours (plus la période de grâce d’export ci-dessus), les données sont purgées conformément au §9 du DPA ; la possibilité d’exporter prend fin avec elles.

Si vous résiliez précisément parce que vous voulez un export final, faites d’abord l’export, vérifiez-le localement, puis résiliez. La fenêtre est généreuse, mais vérifier avant de supprimer est la démarche rigoureuse.

Un seul dépôt ?

L’export complet porte sur toute l’organisation : chaque dépôt avec ses issues, pull requests et releases, l’inventaire des paquets et la tranche d’audit, dans un seul bundle signé. Si vous n’avez besoin que d’un seul dépôt, les voies les plus simples sont :

• git clone --mirror : historique Git complet, branches et tags sous forme de dépôt nu clonable hors ligne. fremforge n’expose pas publiquement le port 22 ; utilisez soit le point de terminaison SSH sur le port 443 (ssh.frem.sh:443), soit la forme 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

  Les empreintes des clés d’hôte de ssh.frem.sh sont publiées sur www.frem.sh/ssh-fingerprints ; vérifiez-les lors de la première connexion. Le résultat est un répertoire prêt pour git bundle ; passez-le à tar -czf pour obtenir un fichier unique portable.

• Téléchargement du dépôt en zip/tarball : frem.sh/<org>/<repo>/archive/<branch>.zip ou .tar.gz pour un instantané d’une seule ref. Pas d’historique, pas de LFS, uniquement l’arborescence de travail de cette branche.

• Issues et PR d’un dépôt en JSON, via l’API : GET /api/v1/repos/<org>/<repo>/issues?state=all&type=issues et ?type=pulls. Les guides de migration montrent la forme de l’appel ; la réponse est du JSON compatible avec l’API GitHub.

L’export signé de toute l’organisation est le bon outil lorsque vous voulez tout (chaque dépôt, ses métadonnées, la tranche du journal d’audit, le manifeste signé) ; les voies par dépôt ci-dessus conviennent au cas courant « je dois envoyer ce dépôt à quelqu’un ».

API programmatique

Le même export est accessible via l’API REST :

# 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)

Spécification OpenAPI : docs.frem.sh/reference/api/.

Garanties de confidentialité

L’export est traçable dans les deux sens :

• Qui a exporté : chaque demande d’export est enregistrée dans votre propre journal d’audit (data-export.requested depuis l’interface d’administration, data-export.queue.api depuis l’API) avec l’utilisateur ou le jeton à l’origine de la demande. Les actions que le support fremverk effectue sur votre organisation sont signalées comme telles dans ce même journal.
• Quelles données : la tranche du journal d’audit est sélectionnée par l’identifiant de tenant de votre organisation ; elle ne contient donc que les événements d’audit de votre propre organisation.
• Hygiène de l’URL signée : l’URL de téléchargement est un lien pré-signé, en lecture seule, vers votre seule archive, valable 7 jours. Passé ce délai, l’URL cesse de fonctionner et l’export disparaît de l’onglet Export de données.

Références croisées

• Tarifs : inclus dans la formule à 30 € par utilisateur ; pas une offre distincte.
• §9 du DPA : l’engagement de restitution des données que cet export remplit.
• Confiance : comment cela s’inscrit dans l’ensemble de notre approche de souveraineté et de maîtrise.