Come verificare il timestamp Bitcoin di un repository Git
Hai una ricevuta .ots nel tuo repository. Ora qualcuno — un avvocato, un revisore, un acquirente che svolge due diligence tecnica — ti pone l’unica domanda che conta: come facciamo a sapere che è autentica?
Questa domanda è il punto centrale dello stato dell’arte crittografico. Un timestamp che non puoi verificare in modo indipendente è solo un’affermazione in un database. Un timestamp che chiunque può verificare contro la blockchain Bitcoin è una prova. Questo articolo illustra il percorso di verifica per i repository ancorati da Timestamp GIT, dal badge nel README fino alla prova di Merkle.
Perché la verifica è importante per i timestamp Git
La cronologia di Git è sorprendentemente facile da contestare. Le date dei commit sono impostate dalla macchina che ha effettuato il commit, quindi possono essere retrodatate con una singola variabile d’ambiente. La cronologia ospitata risiede su server che non controlli, e quella self-hosted vive in un database che qualcuno con diritti di amministratore può riscrivere. In un audit legale, entrambe vengono regolarmente respinte come auto-Referenziali.
L’ancoraggio crittografico colma questa lacuna — ma solo se la prova può essere verificata da una terza parte che non si fida né di te né del fornitore. Questo implica due requisiti:
- La verifica non deve richiedere di fidarsi di Timestamp GIT. La prova è una catena di hash SHA-256 che termina in un blocco Bitcoin. Chiunque può percorrere quella catena con strumenti open source.
- La verifica non deve richiedere di esporre il tuo codice sorgente. Timestamp GIT opera su un modello a conoscenza zero: il servizio riceve gli hash dei commit, mai il contenuto dei file. Non c’è nulla da ispezionare se non gli hash — che è esattamente ciò che vuole un revisore, poiché significa che la prova può essere condivisa senza condividere la codebase.
Per questo design, la verifica è un esercizio crittografico, non una revisione del codice. Revisori, controparte legale o il team di ingegneria di un’azienda acquirente possono tutti validare la stessa ricevuta e giungere alla stessa conclusione.
Come si presenta una prova di Timestamp GIT
Dopo l’esecuzione notturna di ancoraggio, ogni repository monitorato riceve tre artefatti:
- Un manifest giornaliero (
.txt) — l’elenco degli hash dei commit raggruppati per quel giorno, un file per repository. - Una radice di Merkle — il singolo hash SHA-256 calcolato da quel manifest. Tutti i singoli hash collassano in un unico valore.
- Una ricevuta
.ots— la prova OpenTimestamps che lega la radice di Merkle a uno specifico blocco Bitcoin.
Questi artefatti vengono reinseriti nel tuo repository in un branch dedicato ai timestamp, oppure in un repository shadow separato se preferisci mantenere pulito il repo sorgente. In entrambi i casi, le prove sono versionate insieme al codice che attestano, ma in un proprio ref — nulla viene mai committato nei tuoi branch di lavoro.
Due cose meritano di essere affermate chiaramente:
- La prova non contiene alcun codice sorgente. Solo hash dei commit e le loro riduzioni crittografiche.
- La prova non è proprietaria. È una ricevuta OpenTimestamps standard su una transazione Bitcoin, e resta valida indipendentemente dal fatto che Timestamp GIT esista ancora.
Una volta che il file della ricevuta è nel tuo repo, hai tutto il necessario per verificare — il resto sono strumenti.
Verifica passo passo con gli strumenti di Timestamp GIT
Passo 1 — Individua la prova
Apri il branch dei timestamp (o il repo shadow) e trova il manifest per la data in questione, insieme al file .ots corrispondente. Se preferisci non cercare tra i branch, la pagina di stato del repository mostra le stesse informazioni in un browser:
https://timestampgit.dev/status/{user}/{repo}
Passo 2 — Leggi la pagina di stato pubblica
La pagina di stato è il controllo di sanità più rapido. Mostra:
- Longevità della prova e la data di ancoraggio più antica
- Regolarità giornaliera (una heatmap calendario dei giorni ancorati)
- Il blocco Bitcoin e la transazione che portano l’ancora
- Link per il download del CSV di audit e del certificato PDF
Per i controlli automatizzati, gli stessi dati sono esposti come JSON:
# Ultimo blocco Bitcoin ancorato
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service
# Numero totale di commit con timestamp
curl -s https://timestampgit.dev/api/statusCount/acme/payments-service
# Riepilogo combinato (usato dai badge Shields.io)
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service
Passo 3 — Verifica una data specifica nel browser
Per la prova a livello giornaliero, usa la pagina di verifica crittografica:
https://timestampgit.dev/verification/{user}/{repo}/{date}
Questa pagina esegue la verifica completa della catena di Merkle multi-livello localmente nel tuo browser. L’hash del commit, il manifest, il percorso di Merkle e l’header del blocco Bitcoin vengono tutti controllati sulla tua macchina — la pagina non carica ciò che stai verificando. Questa proprietà è importante quando il repository è privato o sotto NDA: il revisore può confermare la prova senza che il fornitore venga a sapere quale data gli interessava.
Passo 4 — Scarica il registro di audit o il certificato PDF
I team di conformità di solito necessitano di un artefatto da archiviare. Entrambi sono a una richiesta di distanza:
# Registro di audit completo in CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv
# Certificato PDF per un giorno
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf
Passo 5 — Facoltativamente, incorpora un badge di verifica
Il widget badge su /connected/{user}/{repo} ti offre un’anteprima live e uno snippet Markdown pronto da incollare per il tuo README. Inseriscilo e chiunque — un cliente, un investitore, un potenziale acquirente — può cliccare per arrivare alla vista di verifica pubblica:
<!-- Snippet copied from https://timestampgit.dev/connected/acme/payments-service -->
[](VERIFY_LINK)
Ogni passo sopra funziona con il flusso di lavoro gestito della GitHub App. Installi l’app una volta, e la verifica è un caricamento di pagina o una richiesta HTTP — nessuno strumento da riga di comando, nessuna gestione manuale del protocollo, nulla da mantenere sulle macchine degli sviluppatori.
Interpretare i risultati della verifica e i casi limite
Una verifica riuscita ti dice qualcosa di ristretto e potente: l’hash del commit esisteva al momento o prima del timestamp del blocco Bitcoin referenziato dalla ricevuta, e la prova di Merkle collega quello specifico hash a quel blocco. Poiché i blocchi Bitcoin non possono essere riscritti senza rifare il proof-of-work, il limite “al momento o prima” è assoluto.
Alcune situazioni si presentano regolarmente:
- Nessuna prova per una data specifica. Di solito significa che non ci sono stati commit quel giorno — il manifest è costruito dagli hash in sospeso, quindi un giorno vuoto non produce nulla da ancorare. Controlla la heatmap sulla pagina di stato per confermare.
- Conferma in sospeso. L’ancoraggio è un processo in due fasi. Il cron worker notturno raggruppa gli hash, costruisce l’albero di Merkle e invia la radice ai calendari OpenTimestamps pubblici; la conferma in un blocco Bitcoin richiede poi alcune ore — normalmente circa tre. Una prova scritta poco dopo mezzanotte potrebbe quindi non essere definitiva fino a più tardi quella mattina.
- Repository privati. L’accesso alle pagine di stato e verifica per i repo privati richiede un HMAC cifrato aggiunto all’URL. L’HMAC è specifico dell’istanza server, quindi i link non possono essere riprodotti contro un’altra distribuzione.
- Indipendenza dal fornitore. Se preferisci non usare affatto il verificatore ospitato, scarica il file
.otsed eseguilo tu stesso con gli strumenti OpenTimestamps open source contro la blockchain Bitcoin. È la strada difficile, ed è più lenta, ma esiste — e la sua esistenza è ciò che rende credibile il percorso gestito.
Verifica in ambienti enterprise e self-hosted
Modalità Enterprise ZK. Una GitHub Action di 12 righe viene eseguita sulla tua infrastruttura e invia solo gli hash dei commit all’API di Timestamp GIT. Il servizio non ha mai accesso in lettura al repository sorgente; ti serve solo l’accesso in lettura-scrittura al repository di destinazione che riceve le prove. La verifica è invariata — gli stessi file .ots, gli stessi dati pubblici di Bitcoin, gli stessi controlli di Merkle nel browser.
Docker self-hosted. Per ambienti air-gapped, Timestamp GIT è distribuito come immagine Docker che esegui tu stesso. Un setup Docker Compose di avvio rapido è simile a questo:
services:
timestampgit:
image: rue1401/timestampgit:prod
ports:
- "8080:8080"
volumes:
- ./data:/app/data
restart: unless-stopped
valkey:
image: valkey/valkey:8
restart: unless-stopped
docker compose pull
docker compose up -d
docker compose logs -f timestampgit
L’istanza è disponibile su http://localhost:8080, e una procedura guidata al primo avvio ti accompagna nel collegamento della tua GitHub App e nella configurazione della distribuzione. La verifica funziona interamente all’interno della tua rete: i file .ots, i manifest e il verificatore locale sono tutto ciò che ti serve.
Una licenza demo a tempo limitato per la valutazione è disponibile inviando il modulo di richiesta sulla pagina della licenza Docker con nome, azienda, email e numero di telefono opzionale; il file di licenza può essere scaricato immediatamente.
Automatizzare la verifica per i team di conformità
La verifica manuale va bene per un singolo audit. La conformità continua la vuole in una pipeline. L’API REST copre questo caso:
#!/usr/bin/env bash
set -euo pipefail
REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"
# Dati della catena di Merkle per la verifica locale di un giorno specifico
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"
# Registro di audit mensile
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"
# Certificato PDF per ogni giorno ancorato
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"
Per le dashboard, esegui il polling degli endpoint di stato invece del payload completo di verifica:
# Invia /api/statusLast e /api/statusCount al tuo sistema di monitoraggio
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"
Un pattern utile è trattare uno statusLast obsoleto come condizione di allarme: se l’ultimo blocco ancorato non si è mosso da più di un giorno per un repo con commit attivi, qualcosa nella pipeline richiede attenzione. Tutti i calcoli di verifica avvengono localmente nel browser o all’interno del tuo script — nessun payload sensibile lascia il tuo controllo. Se stai ancora configurando il lato dell’ancoraggio, vedi Automated Git Timestamping: How a GitHub App Anchors Every Commit; questo articolo riguarda deliberatamente ciò che accade dopo.
FAQ
Devo eseguire strumenti da riga di comando per verificare una prova di Timestamp GIT?
No. Timestamp GIT fornisce una pagina di verifica web che esegue tutti i controlli crittografici localmente nel tuo browser. Puoi anche scaricare il file .ots e usare gli strumenti OpenTimestamps standard se preferisci, ma il servizio gestito non richiede l’uso della CLI.
Posso verificare un timestamp senza fidarmi di Timestamp GIT?
Sì. La prova si basa esclusivamente su hash SHA-256 e dati dei blocchi Bitcoin. Puoi verificare in modo indipendente il file .ots contro la blockchain Bitcoin usando strumenti OpenTimestamps open source, garantendo l’indipendenza dal fornitore.
Quanto tempo ci vuole perché un timestamp diventi verificabile? Dopo che il cron job notturno ancora la radice di Merkle in una transazione Bitcoin, occorrono tipicamente circa 3 ore perché la transazione venga confermata in un blocco Bitcoin. Una volta confermata, la prova è immutabile e verificabile.
Posso verificare i timestamp per repository privati? Sì, ma l’accesso alle pagine di stato e verifica per i repository privati richiede un HMAC cifrato aggiunto all’URL. Questo garantisce che solo gli utenti autorizzati possano visualizzare i dettagli della prova.
Conclusione
La verifica è il punto in cui un timestamp smette di essere una promessa e diventa una prova. La catena è breve e controllabile: hash del commit → manifest giornaliero → radice di Merkle → blocco Bitcoin. Che tu la confermi sulla pagina di stato, esegua la verifica di Merkle nel browser o scarichi il registro CSV per un deposito, la conclusione si basa sulla matematica di Bitcoin piuttosto che sulla parola di chiunque — inclusa la nostra.
Installa la GitHub App su un repository, lascia che l’esecuzione notturna faccia il suo lavoro, poi verifica tu stesso una data prima che qualcuno te lo chieda. Richiede pochi minuti ed è la differenza tra “pensiamo di poterlo dimostrare” e “ecco la prova”.
Post correlati
- Automated Git Timestamping: How a GitHub App Anchors Every Commit
- Protecting Intellectual Property: A Guide for Software Developers
- Prior Art Protection for Software Startups: A Guide