Le format .obf

Une archive .obf est faite pour durer plus longtemps que l’application qui l’a écrite. Elle n’est pas un fichier fermé : c’est un dossier qui contient des fichiers aux formats ouverts et un inventaire lisible. Ce chapitre décrit ce qu’il y a dedans, et ce que vous pouvez en faire sans Obscura Vault.

Compatibilité avec Obscura Flow

Le format .obf est celui d’Obscura Flow 2.0.8, sans modification. Vault lit, vérifie et restaure les archives écrites par Flow (tar, tar.gz, zip, zstd, chiffrées ou non ; une révision incrémentale se lit, se vérifie et se restaure à partir de sa chaîne, et ses seuls fichiers s’extraient, voir Restaurer une révision incrémentale), et écrit ses propres archives dans ce même format. Des archives écrites par Flow sont gardées comme preuve de compatibilité, et chaque version de Vault vérifie qu’elle sait encore les lire, en vérifier la signature, les déchiffrer et les restaurer à l’identique.

Pour vérifier et restaurer les archives de Flow, Vault a besoin des clés de Flow : voir Clés et sécurité.

Ce que contient une archive

Une archive est un dossier nommé d’après le projet et la révision :

Mariage Dupont-v2/
├── Mariage Dupont-v2.tar.zst    le contenu : tout le dossier du projet, compressé (et chiffré si demandé)
├── manifest.json                l'inventaire, lisible
├── signature.ed25519            la signature de l'inventaire
├── inventory.json               l'annexe d'inventaire : l'état complet du projet (Vault seulement)
└── inventory.ed25519            la signature de l'annexe (Vault seulement)

Les trois premiers fichiers sont le format d’Obscura Flow. Les deux derniers sont ajoutés par Vault à chaque archive qu’il crée : voir L’annexe d’inventaire.

Le contenu

Le fichier de contenu porte l’extension de son format :

Format choisi	Fichier de contenu
zstd	`….tar.zst`
tar.gz	`….tar.gz`
tar (sans compression)	`….tar`
zip	`….zip`

Il contient tout le dossier du projet, sous-dossiers et dossiers vides compris, avec leur structure : exactement les fichiers que liste le manifeste, rien d’autre (ni lien symbolique ni cible de lien). Une révision incrémentale (écrite par Vault ou par Obscura Flow) ne contient que les fichiers changés depuis la révision dont elle part : elle n’est jamais restaurée seule, mais avec toute sa chaîne de révisions.

Le manifeste

manifest.json est l’inventaire de l’archive, en JSON. On y trouve notamment :

archiveId, projectName, archiveName, revision (et baseRevision pour une révision incrémentale) ;
engine (le format), createdAt, createdBy (« Obscura Vault » ou Obscura Flow) ;
payloadFile et payloadChecksum : le nom du fichier de contenu et son empreinte SHA-256, telle qu’il est sur le disque (chiffré, s’il l’est) ;
files : la liste de tous les fichiers, avec leur chemin, leur taille et leur empreinte SHA-256 ;
fileCount, totalSourceSize ;
signatureAlgorithm (ed25519) et publicKeyFingerprint : l’empreinte SHA-256 de la clé publique qui a signé ;
isEncrypted et encryptionAlgorithm (aes-256-gcm).

La signature

signature.ed25519 est une signature Ed25519 des octets exacts de manifest.json. Modifier un seul caractère du manifeste rend la signature invalide. Comme le manifeste contient l’empreinte du contenu, la signature protège aussi le contenu : vérifier la signature puis l’empreinte du contenu suffit à prouver que l’archive n’a pas bougé depuis sa création.

L’annexe d’inventaire

inventory.json décrit l’état complet du projet à cette révision : tous ses fichiers, avec leur chemin, leur taille et leur empreinte SHA-256, triés par chemin. Pour une archive complète, c’est la même liste que celle du manifeste. Elle sert surtout aux révisions incrémentales, dont le manifeste ne liste que les fichiers changés : l’annexe dit alors aussi quels fichiers n’ont pas changé, et lesquels ont été supprimés.

On y trouve inventoryVersion (1), archiveId, revision (et baseRevision pour une révision incrémentale), manifestSha256, fileCount, totalSourceSize, files et createdBy. manifestSha256 est l’empreinte SHA-256 des octets de manifest.json : l’annexe appartient à ce paquet-là, et ne peut pas être recopiée sur un autre.

inventory.ed25519 est la signature Ed25519 des octets exacts de inventory.json, faite avec la même clé que le manifeste.

Quand Vault vérifie une archive (« Vérifier », audit d’intégrité, restauration, envoi hors site), il contrôle aussi l’annexe si elle est là : sa signature, son lien avec le manifeste, et son accord avec lui (mêmes fichiers, mêmes empreintes, totaux exacts). Une annexe qui ne correspond pas rend l’archive non conforme : « L’annexe d’inventaire (inventory.json) ne correspond pas à cette archive : l’archive est altérée. » Une archive sans annexe (écrite par Obscura Flow ou par Vault 1.0) se vérifie comme avant.

L’annexe ne change rien aux trois fichiers du format : le manifeste et sa signature restent identiques, octet pour octet, à ce qu’écrirait Obscura Flow, qui lit ces archives en ignorant l’annexe. Elle n’est pas encore envoyée avec les copies hors site.

Le chiffrement

Une archive chiffrée l’est en AES-256-GCM, par blocs de 4 Mio authentifiés chacun : un bloc tronqué ou modifié ne s’ouvre pas. Seul le contenu est chiffré ; le manifeste et la signature restent lisibles, ce qui permet de vérifier une archive chiffrée sans sa clé. Pour la restaurer, il faut la clé de chiffrement.

Sans Obscura Vault

Une archive non chiffrée reste exploitable avec les outils standard :

Lire l’inventaire : ouvrez manifest.json (ou inventory.json) dans n’importe quel éditeur de texte.
Contrôler le lien de l’annexe : shasum -a 256 manifest.json doit donner la valeur de manifestSha256 dans inventory.json.
Contrôler le contenu : dans le Terminal, shasum -a 256 "Mariage Dupont-v2.tar.zst" doit donner la valeur de payloadChecksum.
Extraire les fichiers : le contenu est une archive tar, tar.gz ou zip ordinaire. Le tar livré avec macOS sait lire une archive .tar.zst.
Contrôler un fichier extrait : shasum -a 256 chemin/du/fichier doit donner l’empreinte que files indique pour lui.

Vérifier la signature à la main demande un outil qui sache vérifier une signature Ed25519 avec la clé publique de l’archive. Une archive chiffrée demande sa clé de chiffrement et un programme qui connaisse le découpage en blocs décrit plus haut.