Quanto sono sicuri i tag git firmati? Solo sicuro come SHA-1 o in qualche modo più sicuro?

Non c'è contraddizione. Lo stesso Linus ha detto nello stesso discorso :

If I have those 20 bytes, I can download a git repository from a completely untrusted source and I can guarantee that they did not do anything bad to it.

Interpreterei "Git usa SHA-1 non per sicurezza" poiché "SHA-1 non è stato aggiunto a git per motivi di sicurezza, ma per ragioni di affidabilità, ma la sicurezza è ancora un buon effetto collaterale "e" Le parti di sicurezza sono altrove "poiché" la verifica finale viene eseguita da gpg e git verify-tag ".

Gli ID commit Git non sono "più sicuri" di "bare" SHA-1. Tuttavia, il use cases git è usato per essere più resistente contro gli attacchi di collisione, rispetto alla maggior parte degli altri casi di utilizzo di SHA-1.

Ad esempio, SHA-1 nei certificati è pericoloso. Qualcuno potrebbe creare due certificati con lo stesso hash e per diversi nomi di dominio. Uno (quello "legittimo") viene inviato in un CSR a una CA e l'altro tenuto privato fino a quando non viene utilizzato su alcune vittime con la firma dalla CA. Per gli attacchi di collisione, se l'attaccante cambia la preimage su una parte (come il campo del nome di dominio del certificato), deve anche cambiarla in un'altra posizione. Mentre l'autore dell'attacco ha la libera scelta per i due nomi di dominio, le altre modifiche sono per lo più fisse. In particolare, sono binari e non possono far parte di nessuna parte del cert leggibile dall'uomo. Alcuni attacchi li nascondono nelle chiavi pubbliche / private del certificato ( discussione per MD5 ).

Git tuttavia, è usato principalmente per il codice sorgente. Nascondere il tuo {prefisso scelto,} collisione in una diff ASCII recensita dagli umani è molto più difficile. I manutentori di solito fanno domande quando si crea una condizione if sull'indirizzo esadecimale 2ff5e del file logo.png aggiunto nel commit. Presi insieme, è più facile nascondere una backdoor all'interno di un commit, piuttosto che attaccare SHA-1.

Il tag git firmato è solo un checksum SHA1 firmato. Molto semplicemente detto, ogni commit Git è il checksum SHA1 del commit precedente (che contiene anche SHA1 del suo commit precedente che contiene anche il checksum SHA1 del suo commit precedente e quindi ...).

Se trovi un modo, come cambiare qualcosa in un repository, mantenendo invariato lo SHA1 (trovi una collisione), puoi rompere la firma.

Ricorda che git è distribuito VCS. Di solito, ci sono molte persone che hanno i loro cloni. Sarebbe presto individuato, se ci fosse qualcosa di sbagliato.

Inoltre, c'è una grande differenza tra trovare una collisione e trovare una collisione particolare. Ad esempio, è facile trovare 2 dati "casuali" diversi con la stessa somma MD5. Ma AFAIK, come cambiare i dati dati solo leggermente e mantenere invariato MD5 è ancora un problema difficile e SHA1 è molto più strong di MD5.

Tuttavia, se qualcuno è riuscito a trovare un modo per trovare facilmente le collisioni SHA1, allora git avrebbe un problema molto più grande. Git usa SHA1 come ogni indice di oggetti. Se provi a commettere un oggetto colliso SHA1 probabilmente ti romperesti (... non sono sicuro che ...) almeno il commit.

Quanto segue è la mia comprensione.

Git identifica praticamente tutto con gli sha1 sha1. Il tuo tag firmato fa riferimento al commit tramite il suo hash sha1, il commit identifica "l'albero" dal suo hash sha1 e "tree" fa riferimento ai file con gli hash sha1.

Quindi se hai due file con lo stesso hash sha1, puoi sostituirne uno con l'altro e il tag firmato verrebbe comunque validato.

In pratica, penso che il rischio dipenda in larga misura da ciò che conservi nei tuoi repository git. Non abbiamo un attacco di pre-attacco per SHA1 e difficilmente avremo tempo presto. Quindi dobbiamo solo preoccuparci degli attacchi di collisione.

Se si tratta di un codice sorgente leggibile dall'uomo esaminato da revisori umani, il rischio è limitato. Se qualcuno può scivolare in un blocco di spazzatura binaria inspiegabile e un condizionale che fa roba malvagia basata sul contenuto di quel blocco di spazzatura binaria, è probabile che possa infiltrarsi in cose malevole senza doversi preoccupare delle collisioni di sha1.

OTOH se viene utilizzato per archiviare i binari originati da fonti non attendibili, c'è un maggior potenziale di problemi.

" we are unlikely to have any time soon" - hmm. "Attacks only get better".

Gli attacchi di preimage sono molto più difficili degli attacchi di collisione. Un decennio dopo che le prime collisioni sono state dimostrate per MD5 non abbiamo ancora un attacco preimage fattibile.

I would be more worried about two commits which contain "jpeg + innocent code" and "jpeg + evil code"

La complicazione è dovuta al modo in cui i commit git sono strutturati con i dati jpeg e il codice dovrebbe trovarsi nello stesso file. Immagino che potrebbe essere un problema se le persone stanno memorizzando i tarball nel loro repository git o qualcosa del genere.

Un altro scenario possibile sarebbe se qualche codice decidesse cosa fare con un file basato sul rilevamento automatico del tipo di file. Se una collisione di "prefisso distinto scelto" diventa pratica, allora qualcuno potrebbe commettere un file binario dall'aspetto innocuo (un'immagine o così) che ha avuto un sacco di spazzatura in qualche posto. Quindi sostituirlo con un file più pericoloso.

Per fare un confronto con md5 ci sono voluti circa 2 anni per andare dalle collisioni di base a diverse collisioni prefissate scelte.