BagIt: un fascicolo auto-verificante

Un fascicolo digitale che si può verificare solo con il software che l'ha creato non è un fascicolo: è un ostaggio. BagIt, standardizzato nella RFC 8493, risolve il problema nel modo più antico e più solido: mettendo tutto in chiaro, in file di testo, con hash che chiunque può ricalcolare.

L'idea: una cartella che si controlla da sola

Un bag è una normale cartella — oppure uno ZIP — con dentro una convenzione rigorosa. I dati veri stanno in una sottocartella data/, il payload. Attorno ci sono pochi file di testo che dicono cosa dovrebbe esserci, e con quale impronta.

Nessun formato binario, nessun database, nessun indice proprietario. Un bag lo si apre con un editor di testo, e le sue impronte si ricalcolano con gli strumenti a riga di comando di qualunque sistema operativo. Fra vent'anni funzionerà ancora, perché non c'è nulla che possa smettere di funzionare.

acquisizione-2026/ data/ reperto.e01 foto/IMG_0431.jpg il payload manifest-sha256.txt hash di ogni file in data/ tagmanifest-sha256.txt hash degli altri file di testo bagit.txt bag-info.txt versione e codifica · metadati e Payload-Oxum dentro manifest-sha256.txt a72c479e…2378 data/reperto.e01 7f82fc11…f434 data/foto/IMG_0431.jpg Due colonne, testo semplice. Lo stesso formato che legge sha256sum -c su qualsiasi Linux. dentro bag-info.txt Payload-Oxum: 4218301.2 Bagging-Date: 2026-07-11 4.218.301 byte in 2 file. Il controllo più economico che esista: due numeri, zero hash.
Tutto è testo. Il payload sta in data/; ogni altro file esiste per dire cosa dovrebbe esserci dentro data/, e con quale impronta.

I quattro controlli

1. Payload-Oxum — il controllo da un secondo

In bag-info.txt c'è una riga come Payload-Oxum: 4218301.2: il numero totale di byte nel payload, un punto, il numero di file. Verificarlo richiede una scansione delle dimensioni, senza leggere un solo byte di contenuto.

Non è una garanzia crittografica — chiunque può sostituire un file con un altro della stessa lunghezza. È un filtro: se l'Oxum non torna, il bag è rotto e non ha senso spendere venti minuti a ricalcolare gli hash di un disco intero.

2. Completezza

Ogni file elencato nel manifest esiste davvero? E, altrettanto importante, esiste qualche file dentro data/ che non è nel manifest? Il secondo caso è il più insidioso: un file estraneo intrufolato nel payload non altera nessuna impronta di quelli dichiarati, e passerebbe inosservato se si controllassero solo gli hash.

3. Checksum del payload

Si ricalcola l'impronta di ogni file in data/ e la si confronta con il manifest. Probatio supporta dodici algoritmi di manifest: MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, tutti e quattro gli SHA-3, BLAKE2b e BLAKE2s. Un bag può portarne più d'uno, e allora tutti devono tornare.

4. Tagmanifest

E chi controlla il controllore? Il manifest-sha256.txt è un file di testo come gli altri: se qualcuno modifica un reperto e aggiorna la riga corrispondente nel manifest, i checksum tornano tutti.

Per questo esiste il tagmanifest: un secondo manifest che contiene le impronte dei file di tag, manifest compreso. Modificare un reperto ora richiede di alterare tre file in cascata, e l'ultimo — il tagmanifest — non è coperto da nessuno.

Il sigillo esterno, e la transitività

Il tagmanifest è l'ultimo anello. Se lo si sigilla, si è sigillato tutto.

data/ i reperti coperto da manifest hash dei reperti coperto da tagmanifest hash del manifest marca RFC 3161 + firma Ed25519 Una sola marca, sul solo tagmanifest, data certa a tutto il fascicolo. Cambiare un reperto obbliga a cambiare il manifest, che obbliga a cambiare il tagmanifest, che è marcato. Marcare cinquantamila file costerebbe cinquantamila marche. Marcarne uno basta.
La transitività degli hash è il motivo per cui un fascicolo da mille reperti si sigilla con un solo token. È il medesimo principio dell'albero di Merkle.

Il livello CERTO/LOCUS

Quando dentro data/ compare un file manifest.json, Probatio riconosce un bundle prodotto da CERTO o LOCUS e attiva una validazione aggiuntiva, sopra quella BagIt:

  • Firma Ed25519 del manifest, che lega il fascicolo allo strumento che l'ha creato.
  • Marche temporali RFC 3161 come sidecar .tsr, fra cui — quando c'è — quella sul tagmanifest-sha256.txt, che è il sigillo esterno di cui sopra.
  • Grafo CASE/UCO in JSON-LD: la descrizione formale, in uno standard internazionale, di cosa è stato acquisito, quando, con quale strumento e in quale relazione con gli altri reperti.

Questo livello è additivo. Un bundle CERTO resta un bag BagIt valido, apribile e verificabile da chiunque non abbia mai sentito nominare CERTO.

Perché uno standard del 2008 è ancora la scelta giusta

BagIt nasce alla Library of Congress per trasferire archivi digitali fra istituzioni che non condividono software. Il requisito era esattamente il nostro: chi riceve deve poter verificare senza fidarsi di chi invia.

È lo stesso requisito del contraddittorio. La controparte non deve installare il tuo software per controllare il tuo fascicolo. Deve poter aprire una cartella, leggere un file di testo, ricalcolare degli hash con strumenti che ha già.

Un formato proprietario, anche perfettamente sicuro, sposta il problema: bisogna fidarsi del verificatore. Un bag no. Il verificatore è sha256sum.

In pratica

  1. Non toccare mai un bag «solo per guardare». Aprire un file può cambiarne le date; alcuni formati si riscrivono all'apertura. Lavora su una copia.
  2. Se l'Oxum non torna, fermati. Il bag è incompleto o corrotto, e ricalcolare gli hash è tempo perso.
  3. Un file estraneo in data/ invalida il bag anche se tutti i checksum tornano. Non è un cavillo: è il punto.
  4. Preferisci due algoritmi di manifest, per esempio SHA-256 e SHA3-256. Costa una lettura sola.
  5. Marca il tagmanifest, non i singoli reperti. Una marca, un fascicolo.

Un bag non è un contenitore intelligente. È un contenitore onesto: dichiara cosa contiene, e ti dà i mezzi per smentirlo. In forensica non serve altro.