Contexte technique

Git utilise depuis 2005 un database adressable par le contenu où chaque objet est identifié par le hachage SHA‑1 (160 bits). Cette approche garantit que deux contenus identiques partagent la même clé et que chaque commit incorpore le hachage du commit précédent, assurant ainsi une intégrité cryptographique propagée à travers l’historique.

Le birthday bound de SHA‑1 indique qu’il faudrait environ 1,4 septillion de fichiers aléatoires pour obtenir une collision accidentelle, un nombre largement hors de portée des projets réels.

Pourquoi SHA‑1 est considéré comme « cassé »

Des attaques de collision ont été publiées : SHAttered (2017) et SHA‑1 is a Shambles (2020). Elles montrent qu’avec des GPU et quelques dizaines de milliers de dollars, il est possible de fabriquer deux fichiers différents ayant le même hachage. Le texte précise que ces attaques restent théoriques pour la plupart des usages, mais elles ouvrent la porte à des scénarios de collision ou de second‑preimage où un acteur malveillant pourrait remplacer un fichier légitime par un fichier malicieux sans que Git le détecte.

Implications de la migration vers SHA‑256

Git 3.0 prévoit de remplacer SHA‑1 par SHA‑256 comme algorithme de hachage par défaut. SHA‑256 produit un hachage de 256 bits, soit 60 % de bits en plus que SHA‑1. Cette augmentation se traduit directement par des identifiants d’objet plus longs, augmentant la taille des références dans les index, les packs et les bases de données internes.

Le coût de calcul passe également de quelques dizaines de cycles d’instructions à plusieurs centaines, ce qui multiplie le temps CPU nécessaire pour créer, vérifier ou transférer des objets, surtout dans les dépôts très volumineux où des millions d’objets sont manipulés à chaque git fetch ou git push.

Coûts de performance et de stockage

Sur un dépôt de 10 Go contenant 5 M d’objets, le passage à SHA‑256 augmente la taille du pack d’environ 5 % à 10 % selon la densité des chemins de référence. Cette hausse se cumule à l’échelle mondiale : chaque fois qu’un développeur clone un dépôt, il télécharge des octets supplémentaires, ce qui impacte les réseaux de CI/CD et les services d’hébergement.

En termes de CPU, les benchmarks publiés par les équipes de Git montrent que le hachage SHA‑256 consomme environ 2 à 3 fois plus d’énergie que SHA‑1 sur des architectures x86_64 classiques. Sur des serveurs de build massifs, cela se traduit par une augmentation notable de la facture énergétique.

Limites et alternatives

Le texte souligne que, malgré le coût, aucune collision pratique n’a encore été démontrée sur des dépôts réels, et que les attaques nécessitent des ressources financières et matérielles importantes. Il n’existe pas, à ce jour, d’alternative largement adoptée offrant le même niveau de compatibilité tout en restant plus économique que SHA‑256. La migration imposée risque donc de créer une charge globale disproportionnée par rapport au gain de sécurité réel, surtout pour les projets qui ne manipulent pas de données sensibles.