Marca temporale Git: come datare il codice sorgente

Le date dei commit Git non dimostrano quando il tuo codice esisteva. Chiunque può impostarle a piacere, e un rebase le riscrive. Per fissare una data su una codebase che un estraneo, un cliente o un giudice devono poter accettare, prendi un'istantanea esatta del codice – di solito lo ZIP di un commit con tag – e applica una marca temporale elettronica qualificata alla sua impronta. Dal tuo computer esce solo l'impronta, quindi funziona anche per codice privato e proprietario. Ecco la procedura esatta, cosa stabilisce e cosa no.

Informazioni generali sulle prove, non una consulenza legale per una controversia specifica.

Perché la cronologia Git non è una prova indipendente di una data

Git registra due date su ogni commit, la data dell'autore e quella del committer, ed entrambe vengono dalla macchina che crea il commit. Nessuno le verifica. Impostando GIT_AUTHOR_DATE e GIT_COMMITTER_DATE prima di un commit, oppure lanciando git commit --amend --date, ottieni una cronologia che dice quello che vuoi tu. Rebase interattivi, squash merge e cherry-pick riscrivono le date come effetto collaterale del lavoro di tutti i giorni.

Questo non rende inutile la tua cronologia. È un'ottima prova di come è stato costruito il codice: piccoli passi, ragionamenti nei messaggi di commit, issue, review, branch abbandonati. È una prova debole del quando, perché chi la porta è la stessa persona che avrebbe potuto scriverla.

Le piattaforme di hosting aiutano, ma non colmano il vuoto. GitHub, GitLab e Bitbucket registrano quando un push le ha raggiunte, ma quei dati sono in mano a un'azienda privata, possono essere difficili da ottenere in seguito e spariscono con un repository o un account cancellato. Un force-push sostituisce ciò che c'era prima.

Cosa aggiunge una marca temporale qualificata

Una marca temporale elettronica qualificata è rilasciata da un prestatore di servizi fiduciari vigilato ai sensi del regolamento eIDAS dell'UE. In base all'articolo 41, paragrafo 2, i giudici di ogni Stato membro presumono che la sua data e ora siano esatte e che i dati a cui si riferisce non siano cambiati da allora. La data non viene da te, quindi non può essere contestata sostenendo che l'hai impostata tu.

La marca temporale è legata all'impronta SHA-256 di un file. Basta cambiare un solo byte e l'impronta non corrisponde più. Per questo il metodo che segue consiste nello scegliere e conservare un file esatto.

In Italia esiste anche il Registro Pubblico Speciale per i programmi per elaboratore, tenuto dalla SIAE. L'iscrizione è facoltativa e non fa nascere alcun diritto: il diritto d'autore sul software sorge con la creazione dell'opera. Il registro e la marca temporale sono strumenti diversi e possono convivere.

Metodo 1: marca temporale sullo ZIP di un commit con tag (il più solido)

1. Applica un tag allo stato che vuoi fissare. git tag v1.4.0 (oppure usa un commit che hai già taggato).
2. Esporta esattamente quello stato. git archive --format=zip -o mioprogetto-v1.4.0.zip v1.4.0. L'archivio contiene i file tracciati in quel commit e nient'altro: niente .env, niente output di build, niente modifiche non committate.
3. Fatti rilasciare un certificato per quello ZIP. L'impronta viene calcolata nel tuo browser; lo ZIP non viene caricato. Sono accettati file fino a 500 MB.
4. Conserva lo ZIP senza modificarlo accanto al PDF del certificato, in almeno due posti. Non estrarlo e non ricomprimerlo: un nuovo archivio con gli stessi file può comunque avere un'impronta diversa.

Perché uno ZIP e non la cartella: il certificato copre un solo file. Un archivio trasforma l'intero albero in un unico file, la cui impronta puoi ricalcolare in seguito con qualsiasi strumento SHA-256. L'output di git archive può variare tra versioni di Git, ed è proprio per questo che conservi l'archivio su cui hai applicato la marca invece di pensare di rigenerarlo.

Metodo 2: marca temporale su un riepilogo del commit (leggero)

Se vuoi datare molti commit spendendo poco, o se il repository supera i 500 MB, scrivi un breve file di testo e applica la marca temporale a quello:

repository: git@example.com:me/mioprogetto.git
tag: v1.4.0
commit: 3f9c2e7d0a5b8c1e4f6a9d2b7c0e3f5a8b1d4c6e
tree: 9b2e4d6f8a0c1e3b5d7f9a1c3e5b7d9f0a2c4e6b
note: release candidate inviata al cliente su richiesta

Compila le righe commit e tree con i valori reali di git rev-parse v1.4.0 e git rev-parse v1.4.0^{tree}. L'ID di un commit Git è un hash calcolato sull'albero del commit, sui suoi genitori e sul suo messaggio, quindi lega la marca temporale a quello stato esatto del codice e a tutta la cronologia precedente. Conserva al sicuro il repository, compreso quel commit: senza di esso il file di testo da solo non dimostra nulla.

Il compromesso: il collegamento tra il file di testo e il tuo codice dipende dall'hashing di Git. La maggior parte dei repository usa ancora SHA-1 per gli ID degli oggetti, un algoritmo con attacchi di collisione noti, anche se Git include un sistema di rilevamento per quello conosciuto. Per una tappa di routine di solito basta. Per la versione su cui con più probabilità farai affidamento in una controversia, usa il Metodo 1, dove la marca temporale copre i file stessi.

Quale usare e quando

Codice privato e proprietario

L'impronta viene calcolata sul tuo dispositivo. A meno che tu non scelga esplicitamente di conservare una copia del file, StampR riceve solo l'impronta, il nome e la dimensione del file e i dati che inserisci. Dall'impronta non si può risalire al codice. Per il codice proprietario lascia deselezionata l'opzione per conservare e mostrare l'originale: un originale conservato viene mostrato sulla pagina pubblica del certificato.

Scegli il nome del file e la descrizione con la stessa cura. Entrambi compaiono sul certificato. mioprogetto-v1.4.0.zip va bene; un nome che rivela un prodotto non ancora annunciato forse no.

Cosa non fa

• Non dimostra che il codice l'hai scritto tu. Attesta che quel codice esatto esisteva in quel momento e che lo hai dichiarato tuo. La cronologia dei commit, le issue e le note di progettazione mostrano il lavoro mentre veniva fatto.
• Non stabilisce a chi appartiene il codice. Nell'UE, quando un dipendente crea un programma nell'esercizio delle sue mansioni, è il datore di lavoro a poter esercitare i diritti economici, salvo diverse disposizioni contrattuali (direttiva 2009/24/CE, articolo 2, paragrafo 3; in Italia art. 12-bis della legge 633/1941). Per il lavoro da freelance o in agenzia decide il contratto. Una marca temporale fissa delle date, non scavalca un accordo.
• Non copre un'idea o un algoritmo in quanto tali. Il diritto d'autore sul software nell'UE riguarda la forma espressiva di un programma, non le idee e i principi alla sua base (direttiva 2009/24/CE, articolo 1, paragrafo 2). Le questioni brevettuali sono separate, e la pubblicazione può incidere su di esse.
• Non sostituisce una licenza. Se pubblichi del codice, scegli e includi una licenza: la marca temporale è una prova, non un'autorizzazione.

Applica una marca temporale a un'istantanea del tuo codice – il primo certificato con un account costa 4,90 €.

Verificarlo in seguito

Chiunque può verificare il certificato senza doversi fidare di te. Esegui sha256sum mioprogetto-v1.4.0.zip (macOS: shasum -a 256, Windows: Get-FileHash), poi confronta il risultato con l'impronta sul certificato, oppure inseriscilo nella pagina di verifica. Se corrisponde, il file è identico byte per byte a quello su cui è stata applicata la marca temporale.

Da leggere anche

• Centinaia di file con un solo certificato – il metodo del manifest, per quando uno ZIP non è pratico.
• Le marche temporali reggono in tribunale? – cosa fa la presunzione eIDAS in una controversia.
• Documentare la paternità: tutte le opzioni a confronto – compreso quando una marca temporale è lo strumento sbagliato.

Domande frequenti

Le date dei commit Git possono servire come prova di quando è stato scritto il codice?

Si possono presentare, ma sono deboli sul piano temporale perché le imposta la macchina che crea il commit e si possono cambiare con variabili d'ambiente, amend o rebase. Sono una prova solida di come si è sviluppato il lavoro, e rendono al meglio insieme a una data indipendente come una marca temporale qualificata.

Devo caricare il mio codice sorgente?

No. L'impronta SHA-256 viene calcolata nel tuo browser e viene inviata solo l'impronta, a meno che tu non scelga di conservare una copia del file. Per il codice proprietario non conservare una copia.

Meglio marcare lo ZIP o l'hash del commit?

Lo ZIP di un commit con tag è l'opzione più solida, perché la marca temporale copre direttamente i file. Un file di testo con l'ID del commit costa meno per le tappe regolari e copre tutta la cronologia precedente, ma il suo collegamento con il codice dipende dall'hashing di Git.

Basta l'orario di un push su GitHub?

È un utile elemento di supporto, ma è custodito da una piattaforma privata, può essere difficile da ottenere in seguito e sparisce se il repository o l'account vengono cancellati. Una marca temporale qualificata la custodisci tu, e i giudici dell'UE ne presumono l'esattezza.

Una marca temporale dimostra che il codice è mio?

No. La titolarità dipende da chi l'ha scritto e dai contratti di lavoro o di collaborazione. La marca temporale fissa che quel codice esatto esisteva in un dato momento e che lo hai dichiarato tuo.

Ogni quanto conviene applicare una marca temporale?

Nei momenti a cui potresti dover fare riferimento in futuro: prima di consegnare codice a qualcuno, prima di un cambio di licenza, alla fine di un contratto e alle release importanti. Molti sviluppatori aggiungono nel mezzo un riepilogo mensile dei commit.