Il git commit hash dimostra la storia fino a quel momento?

Non contro agenti sofisticati con molte risorse. SHA-1 (l'hash utilizzato in git) non è considerato crittograficamente sicuro in questi giorni contro gli attacchi di collisione. Con i metodi pubblicati per un la collisione totale è stimata a circa ~ $ 100.000 nel tempo di elaborazione EC2 . Questo è il motivo per cui i certificati SSL SHA-1 sono considerati non sicuri.

Se si ignora la possibilità di attacchi di collisione SHA-1, se si consegna a qualcuno un hash di commit (e successivamente gli si dà accesso al repository), possono usare quell'hash di commit per verificare le seguenti informazioni (che è stato sottoposto a hash insieme in un formato personalizzato per creare l'hash):

1. l'intero hash sha1 dell'albero corrente (l'albero è essenzialmente un elenco di file di un commit con nomi di file che puntano agli hash sha-1 dei dati nei file)
2. l'intero hash sha1 dei commit parent (multipli in caso di unione)
3. Il nome e l'e-mail dell'autore e del committer,
4. Il timestamp del commit (secondo il computer locale del committer)
5. Il messaggio di commit

Quindi, se invii un'email a una persona con un hash di commit specifico 43c5ab273a7c897dfd8cad9cef829b3a657f8491 in un determinato momento, è possibile verificare successivamente che sia stato effettuato il commit indicando un albero specifico ( 4c883b33dbb987e46c211f6dad52b91b208661b4 ) con un commit padre di cef37643eb57177ac9e4e1f3d0178bc67b381c8e . Verranno incluse anche le informazioni su timestamp e autore / committente, ma ciò non dovrebbe essere considerato attendibile. Ad esempio, chiunque può dire alla loro istanza locale di git che sono qualsiasi nome / email che vogliono e spingerlo in un repository di bitbucket che controllano.

Nota, quindi se qualcuno vuole verificare che tu abbia un repository in un certo modo il mese scorso, puoi facilmente tornare indietro e modificare la cronologia e creare un nuovo commit (con un nuovo hash) che mostra che il repository era così in quella volta. Tuttavia, se avessi dato loro un hash per il commit dello stato del repository in quel momento, ciò non sarebbe possibile (senza passare attraverso la difficoltà di generare collisioni hash).

Come spiega dr jimbob, git di default non è abbastanza sicuro come probabilmente ti piacerebbe per questa applicazione. Tuttavia, esiste un'opzione per questo tipo di situazione, ovvero per firmare i tuoi commit o tag con GPG .

Se lo fai, allora hanno una garanzia potenzialmente molto più strong di aver creato questo lavoro; ora ti stai affidando principalmente a GPG e alla rete di fiducia per fare la verifica, piuttosto che git stessa. Le solite cose GPG si applicano, ad es. devono fidarsi della tua chiave, devi tenere la tua chiave al sicuro, ecc.

Si noti inoltre che se si firma un particolare commit, si sta verificando l'autenticità dell'intera cronologia del commit che porta a quello. Nel tuo caso, questo non dovrebbe essere un problema, dal momento che sei l'unico responsabile del repository, ma è qualcosa da tenere a mente mentre lavori.

Questo potrebbe fornire ancora problemi nel provare il tempo . Quella informazione è memorizzata in un commit, ma puoi controllarla (ovviamente modificando il tuo orologio di sistema). Quindi quello che abbiamo alla fine di questo è una buona garanzia che hai impegnato un particolare testo in ciò che rivendichi è un certo tempo . Se vuoi garantire che non hai dati post-datati, dovrai coinvolgere un sistema esterno con un orologio attendibile.