Le SHA-256 par défaut de Git 3.0 est une erreur coûteuse, selon Chacon

Scott Chacon affirme que le projet de Git de faire de SHA-256 le hachage par défaut des nouveaux dépôts dans la version 3.0 sera une erreur coûteuse. Son argumentaire, publié sur le blog de GitButler le 30 septembre 2026, arrive alors que le projet Git lui-même dit que la bascule attendra que l'écosystème soit prêt. Le débat compte parce que chaque outil qui stocke ou analyse un identifiant de commit Git est concerné par la réponse.

Tech AI Wire a présenté le plan Git 3.0 en septembre. Les nouveaux dépôts recevront des noms d'objets SHA-256, le format reftable et une branche main, et la compilation de Git exigera Rust.

Ce qu'avance Chacon

Git identifie chaque fichier, dossier et commit par un hachage, une empreinte de longueur fixe calculée à partir de son contenu. Git utilise l'algorithme SHA-1 pour cela depuis le début. SHA-1 est connu pour être faible. Avec assez d'efforts, des chercheurs peuvent produire deux entrées différentes ayant la même empreinte, ce qu'on appelle une collision.

La thèse de Chacon est que cette faiblesse est théorique pour Git. Aucune collision n'a été documentée dans des milliards de dépôts Git, écrit-il, malgré les failles mathématiques connues de SHA-1.

Il énumère ensuite le coût. Un dépôt SHA-256 casse tous les hachages SHA-1 existants. Les URL, les références de commits dans les gestionnaires de bugs et tout ce qui cite un identifiant de 40 caractères ne correspondent plus. La plupart des bibliothèques Git, dit-il, ne prennent pas totalement en charge SHA-256.

Son alternative consiste à vérifier l'intégrité sans changer les noms d'objets. Chacon rapporte que hacher un arbre complet extrait est rapide. Ses tests ont pris environ 5 secondes pour l'arbre Chromium de 35 Go et 2,1 millions de fichiers, et 257 millisecondes pour le noyau Linux de 1,5 Go. Il propose d'intégrer des sommes de contrôle SHA-256 dans des objets signés, à côté des noms SHA-1. Un projet pourrait alors vérifier avec le hachage le plus fort sans scinder l'écosystème en deux. Il cite git-evtag, un outil de 2015, comme précédent de cette idée.

Ce que dit le projet Git

Le document des changements incompatibles de Git décrit le plan que Chacon conteste. Git 3.0 change le hachage par défaut en SHA-256 uniquement pour les dépôts nouvellement initialisés. Les dépôts SHA-1 existants continuent de fonctionner, et le document indique qu'il n'est pas prévu de déprécier le format d'objets SHA-1.

Le document explique aussi pourquoi le projet veut ce changement. Il qualifie SHA-1 de cryptographiquement cassé et énumère les preuves.

Étape	Année
Le NIST déprécie SHA-1	2011
Attaque SHAppening	2015
Collision SHAttered	2017
Git choisit SHA-256 comme successeur	fin 2018
Attaque par quasi-collision d'anniversaire	2019
Attaque Shambles	2020

Deux points du document jouent en faveur de Chacon. Le projet Git dit qu'il ne fera pas le changement tant que les bibliothèques, les plateformes d'hébergement et les applications tierces n'auront pas montré qu'elles sont prêtes pour SHA-256. Et il ne fixe aucune date de sortie pour Git 3.0. Des informations antérieures situaient la sortie vers la fin 2026 ; le document lui-même ne donne aucune date.

Comment la transition est censée fonctionner

Le document de conception de la transition de fonction de hachage de Git montre que le projet a réfléchi à l'interopérabilité. Le choix de SHA-256 remonte à la fin 2018. La conception permet à chaque dépôt de migrer à son propre rythme. Un dépôt SHA-256 tient une table de traduction dans les deux sens, de sorte qu'un objet peut être désigné par l'un ou l'autre hachage pendant la transition.

Les opérations réseau sont aussi couvertes. La conception décrit les push et fetch entre serveurs SHA-256 et SHA-1, avec conversion des objets lors de l'empaquetage. Les commits peuvent porter deux signatures, l'une dans le champ existant gpgsig et l'autre dans un nouveau champ gpgsig-sha256. Le travail est découpé en cinq phases et se termine par une transition complète une fois qu'assez de dépôts ont migré. Deux limites subsistent : les clones superficiels et les alternates ne fonctionnent pas entre dépôts SHA-1 et SHA-256.

La différence visible est la longueur. Un nom d'objet SHA-1 compte 40 caractères hexadécimaux. Un nom SHA-256 en compte 64.

Ce que cela signifie pour les développeurs

Rien ne change pour vous aujourd'hui. Git 3.0 n'a pas de date de sortie, et les dépôts existants restent en SHA-1 de toute façon. La question est de savoir quoi faire avant l'arrivée d'un nouveau défaut, quel que soit le moment.

D'abord, testez dès maintenant vos outils contre un dépôt SHA-256. L'affirmation de Chacon selon laquelle la plupart des bibliothèques Git ne le prennent pas totalement en charge est vérifiable. Créez un dépôt de test en mode SHA-256 et faites tourner dessus vos scripts d'intégration continue, vos hooks de déploiement et vos intégrations de revue de code.

Ensuite, auditez tout ce qui suppose un identifiant de 40 caractères. Les colonnes de base de données, les expressions régulières et les motifs d'URL qui codent cette longueur en dur tronqueront ou rejetteront les noms de 64 caractères. Notre article de septembre faisait la même remarque. Le billet de Chacon rappelle que la casse s'étend à chaque lien stocké.

Enfin, pesez son alternative sur le fond. Si votre préoccupation est la détection d'altérations plutôt que le nommage, des sommes de contrôle signées sur l'arbre le permettent dès aujourd'hui sans changement de format. Si vous avez besoin de noms d'objets SHA-256, la conception de la transition prend déjà en charge une migration par dépôt avec interopérabilité SHA-1. Vous n'avez pas à attendre la 3.0.

Pour finir, surveillez le critère de préparation du projet plutôt que le numéro de version. Le document des changements incompatibles lie la bascule du défaut à la préparation de l'écosystème. Autrement dit, ce sont les forges et les bibliothèques, pas le calendrier des sorties de Git, qui décident quand cela se produira.