Le projet Git vise la fin de l’année 2026 pour le lancement de Git 3.0, avec pour objectif d’imposer SHA-256 comme format d’objet par défaut pour tous les nouveaux dépôts initialisés. Cette version majeure prévoit également de rendre obligatoire la chaîne de compilation Rust, d’adopter le backend reftable par défaut et de supprimer une série de commandes historiques obsolètes. Bien qu’une période de transition subsiste avant la sortie finale, la vérification de la compatibilité de l’ensemble de la chaîne d’outils doit débuter dès maintenant.
Un simple changement de valeur par défaut qui force tout l’écosystème à se revalider
L’équipe centrale de maintenance insiste sur le fait que les dépôts existants au format SHA-1 continueront de fonctionner normalement après la mise à niveau. Cette position officielle cherche à cantonner les ruptures de compatibilité aux seuls nouveaux projets. Cependant, dans les environnements de production réels, modifier le comportement par défaut pour les nouveaux dépôts revient à briser l’évolution fluide de l’écosystème existant. Dès qu’un développeur crée un nouveau dépôt de test en local (git init), les anciennes extensions d’IDE refusent de l’analyser. De leur côté, les scripts de déploiement et d’automatisation non maintenus se heurtent immédiatement au mur des erreurs d’incompatibilité de format.
Le risque fondamental provient de la dépendance structurelle de la chaîne d’outils envers des identifiants hexadécimaux de 40 caractères. Dans les nouveaux dépôts, ces identifiants passent subitement à 64 caractères. Ce saut de longueur réduit à néant d’innombrables règles d’extraction, expressions régulières et analyseurs de journaux développés au cours des quinze dernières années. Les modules de traitement de logs des systèmes d’intégration continue (CI/CD) lèvent des exceptions de troncature ou des erreurs de parsing dès qu’ils rencontrent les métadonnées d’un commit au format SHA-256.
Figure : Git comme base de données clé-valeur basée sur le hachage de contenu. Source : GitButler / Butler’s Log
Git propose une prise en charge expérimentale des dépôts SHA-256 depuis 2018, offrant aux projets à hautes exigences de sécurité la possibilité de migrer volontairement. Pourtant, au cours de cette fenêtre de huit ans, le nombre de projets disposés à endosser les frictions de la migration est resté dérisoire. Forcer le changement de valeur par défaut est donc devenu l’unique levier opérationnel de l’équipe centrale pour impulser une transition globale dans l’industrie.
Pourquoi les attaques par collision ne sont pas des attaques de seconde préimage
Le NIST a officiellement inscrit SHA-1 sur sa liste de dépréciation dès 2011, fixant les orientations des organismes de normalisation depuis plus de quinze ans et imposant son abandon d’ici 2030. L’argument mis en avant par les mainteneurs principaux pour changer la valeur par défaut est sans détour : les nouvelles bases de code ne doivent plus reposer sur un algorithme officiellement désavoué.
Des observateurs critiques comme Scott Chacon, cofondateur de GitHub et de GitButler, soulignent que ce raisonnement amalgame des niveaux de menace cryptographique totalement distincts. La recherche en sécurité a démontré des attaques pratiques par collision contre SHA-1 avec les travaux SHAttered en 2017 et l’article « SHA-1 is a Shambles » en 2020. Toutefois, concevoir délibérément deux fichiers binaires différents produisant la même empreinte de hachage n’a rien de comparable avec une attaque de seconde préimage, où un attaquant devrait forger du code malveillant ciblant un commit préexistant et inconnu sans en altérer l’empreinte.
Dans la pratique de l’ingénierie logicielle, mener une attaque de seconde préimage contre un dépôt existant demeure un défi au coût astronomique et totalement dénué de faisabilité opérationnelle. Même si Git rétrogradait sa vérification d’intégrité vers MD5 — un algorithme aujourd’hui universellement considéré comme vulnérable —, une telle attaque resterait impossible : si l’intégralité des quelque 3 milliards de GPU de la planète était remplacée par des RTX 5090 tournant à plein régime, le temps nécessaire pour calculer une seconde préimage serait encore de l’ordre de 16 milliards d’années. Les capacités matérielles mondiales actuelles sont incapables de combler le gouffre entre une faiblesse mathématique théorique et une exploitation concrète.
Reproduire les attaques par collision académiques au sein des flux de travail réels se heurte également à l’absence de viabilité opérationnelle. Un assaillant devrait d’abord obtenir des droits d’écriture sur le dépôt ciblé, insérer d’immenses blocs d’entropie binaire dans un commit, puis manipuler les mainteneurs amont pour les inciter à fusionner cette branche spécifique. Mettre en place un tel échafaudage pour forcer un merge n’offre aucun retour sur investissement dans le cadre d’activités cybercriminelles réelles.
La confiance dépend de la source de téléchargement, non du hachage
Cette controverse interroge les frontières de sécurité de l’architecture des systèmes de contrôle de version. Linus Torvalds l’affirmait dès la naissance de Git en 2005 : la véritable ligne de défense se situe dans les canaux de distribution, et non dans une formule cryptographique. Ce qui détermine le niveau de sécurité sur la machine d’un développeur, c’est l’authenticité du serveur de confiance duquel proviennent les mises à jour. Cette confiance organisationnelle est infiniment plus déterminante que l’algorithme de contrôle exécuté sur les fichiers du disque local.
Les attaques réelles sur la chaîne d’approvisionnement logicielle privilégient massivement l’ingénierie sociale à la cryptanalyse. Les attaquants préfèrent racheter des paquets open source à l’abandon ou se faire passer pendant de longs mois pour des contributeurs modèles afin d’obtenir des droits de commit légitimes, comme l’a révélé l’incident de la porte dérobée xz en 2024. Obtenir des privilèges d’écriture pour introduire directement un cheval de Troie est infiniment plus rapide, économique et fiable que de mobiliser d’immenses fermes de serveurs pour générer une collision de hash.
Considérer la longueur de l’algorithme comme le rempart principal contre l’injection de code occulte les angles morts d’authentification tout au long des pipelines de compilation et de livraison. Remplacer une archive de release sous un tag pourtant signé validement ne nécessite aucune collision de hachage. Faire barrage au code corrompu relève de la rigueur des canaux de distribution ; étendre la longueur des empreintes ne comblera jamais cette faille organisationnelle.
L’impossible équation financière : deux formats qui refusent de cohabiter
L’aspect le plus épineux du changement de valeur par défaut concerne la migration des dépôts existants, qui ne peut s’effectuer de manière invisible en arrière-plan.
Figure : Interface d’hébergement imposant le choix du format de hachage lors de la création d’un dépôt. Source : GitButler / Butler’s Log
Les équipes opérant sur des forges privées ou auto-hébergées devront synchroniser manuellement les configurations client et serveur. Dès que l’environnement local diverge des capacités de la forge distante, les opérations de push sont bloquées avec l’erreur : fatal: the receiving end does not support this repository's hash algorithm.
Convertir un dépôt historique volumineux revient à réécrire l’intégralité de son historique. Faire passer un dépôt existant de SHA-1 à SHA-256 impose de recalculer l’ensemble des objets blob, tree et commit. Ce redémarrage à zéro invalide instantanément toutes les signatures cryptographiques GPG et SSH associées aux commits passés. De plus, les wikis internes, gestionnaires de tickets et messageries d’entreprise regorgent de liens pointant vers des identifiants à 40 caractères ; après réécriture, ces références se transforment du jour au lendemain en liens morts.
L’architecture des sous-modules de Git accentue encore la fracture de l’écosystème. Selon les spécifications actuelles, un sous-module imbriqué doit partager le même format d’objet que son dépôt parent. Si un projet s’appuie sur une dépendance externe restée sous SHA-1 alors que le projet principal passe à SHA-256, les serveurs d’intégration continue doivent maintenir deux copies indépendantes des formats. Tout décalage dans la gestion de ce double rail paralyse les pipelines d’automatisation de l’équipe.
En outre, les bibliothèques tierces qui réimplémentent Git (comme libgit2) sans recourir aux binaires C officiels accusent un retard important dans leur prise en charge de SHA-256. Des rumeurs indiquent que Google aurait envisagé d’imposer des directives internes obligeant tous les nouveaux projets de l’entreprise à rester sur l’ancien format SHA-1. Les géants de la tech préfèrent geler la mise à niveau de l’infrastructure plutôt que de mobiliser leurs meilleurs ingénieurs sur la résolution d’incompatibilités entre outils.
L’approche alternative : déporter le coût de calcul sur la signature
La volonté de l’équipe de développement d’imposer ce nouveau standard n’est pas fortuite. Les mécanismes de mappage d’interopérabilité entre les formats durant la phase de transition font l’objet d’échanges nourris sur la liste de diffusion de Git depuis des années. Pour les concepteurs de l’infrastructure, accepter des frictions à court terme en échange de décennies de garanties contre toute altération relève d’une trajectoire logique. Les architectes système cherchent naturellement à éradiquer toute vulnérabilité théorique dès la couche de stockage.
À l’inverse, les voix dissidentes au sein de la communauté préconisent de contenir les coûts de défense dans des limites pragmatiques. Des mainteneurs indépendants suggèrent d’éviter la refonte globale de la couche de stockage. Ils proposent plutôt d’injecter un en-tête de validation de contenu calculé séparément (en SHA-256 ou BLAKE3) au sein même de l’objet de signature du commit ou du tag, une démarche proche de l’outil git-evtag développé par Colin Walters.
Figure : Injection d’un hachage de contenu indépendant dans les champs signés d’un objet Git. Source : GitButler / Butler’s Log
Cette conception reporte l’effort de calcul cryptographique exclusivement sur la phase de signature et de vérification. Tout attaquant tentant de falsifier l’historique devrait neutraliser simultanément deux mécanismes de vérification entièrement découplés.
L’avantage majeur de cet en-tête de validation indépendant est d’épargner les activités de développement courantes de toute pénalité de performance. D’après les mesures réalisées, recalculer l’empreinte de l’intégralité de l’arborescence de Chromium (35 Go et 2,1 millions de fichiers) ne réclame que 5 secondes. Pour l’arbre du noyau Linux de 1,5 Go, l’opération prend 257 millisecondes, et tombe à 17 millisecondes sur un projet de taille standard. En concentrant la charge de calcul au moment de l’émission d’un tag de version, le flux quotidien des commits n’a pas à acquitter de taxe supplémentaire sur les performances.
Basculer les dépôts vers un nouveau standard garantit des décennies de marge de sécurité théorique ; maintenir le comportement par défaut épargne à l’écosystème une facture de migration colossale. Les postulats de chaque camp sont limpides : si l’on considère que le hachage de stockage constitue la clé de voûte de la confiance, la transition doit s’opérer sans attendre ; si l’on estime que la confiance découle des sources amont et des canaux de distribution, l’urgence s’estompe. Le mappage d’interopérabilité entre formats débattu de longue date sur les listes de diffusion demeure le seul amortisseur réaliste pour négocier ce tournant.
Liens de référence :
- Git 3.0 and the SHA-256 Migration
- The hidden cost of Git’s SHA-256 migration
