Résumé

  • Le plan officiel de transition de 2018 choisissait SHA-256 et proposait une table de correspondance bidirectionnelle entre anciens et nouveaux noms d’objets. Il décrivait un objectif de migration.
  • Le manuel Git 2.29.0 qualifiait les dépôts SHA-256 d’expérimentaux en 2020. Le manuel Git 2.54.0 indique encore en 2026 qu’ils ne peuvent pas interopérer avec les dépôts SHA-1.

L’étiquette est cousue dans le dossier

Un fichier inchangé peut recevoir un nouvel identifiant calculé avec SHA-256. Pour un blob Git, l’opération paraît presque aussi simple. L’arbre, lui, inscrit les identifiants de ses fichiers et de ses sous-arbres. Le commit inscrit celui de l’arbre et de ses commits parents. Une étiquette peut encore désigner un autre objet. Le document de conception de Git détaille la cascade: changer un nom de référence change les octets de l’objet qui la contient; cet objet obtient à son tour un nouveau nom. Remonter une histoire de commits entraîne donc bien plus qu’un remplacement d’en-tête.

L’ancien espace de noms ne vivait pas seulement dans le dépôt local. Des serveurs, des applications et des outils dépendaient de ces identifiants. Pour qu’un objet conserve une identité compréhensible des deux côtés, il fallait tenir une correspondance entre ses noms SHA-1 et SHA-256. Une fonction de hachage calcule une empreinte; elle ne sait pas, seule, mener une négociation entre deux archives déjà reliées.

Le plan de 2018 proposait cette table dans les deux sens. Il visait une conversion dépôt par dépôt et la communication avec des serveurs SHA-1. Il séparait les étapes de réalisation et laissait la prise en charge d’un nouveau protocole hors de sa première phase. L’ambition était précise, tout comme l’écart entre une architecture publiée et une capacité déployée.

Un bouton dans le manuel, puis un avertissement

En 2020, Git 2.29.0 permettait d’initialiser un dépôt avec --object-format=sha256. Le manuel le présentait comme expérimental, destiné aux essais, et avertissait qu’un tel dépôt ne pouvait généralement pas partager son travail avec un dépôt SHA-1. Construire un entrepôt neuf est une chose; faire circuler ses colis dans l’ancien réseau logistique en est une autre.

Le manuel Git 2.54.0 est encore plus utile pour lire le présent: sha1 reste le format par défaut, sha256 est une option, et il n’existe pas actuellement d’interopérabilité entre dépôts des deux formats. Les années écoulées n’autorisent pas à transformer l’objectif de 2018 en fonctionnalité acquise.

Le document BreakingChanges de Git projette de faire de SHA-256 la valeur par défaut des nouveaux dépôts avec Git 3.0. Il ne fixe pas de date, conditionne le changement à la préparation des bibliothèques, applications et hébergeurs, et ne prévoit pas encore d’abandonner le format SHA-1. Ce calendrier admet deux populations de dépôts. Modifier la porte d’entrée n’efface pas les archives qui occupent déjà le bâtiment.

Le réseau tient le calendrier

Le plan de transition évoquait les faiblesses de SHA-1, dont la collision SHAttered de 2017, pour justifier SHA-256. Mais la sécurité du nouveau calcul ne supprimait ni les références inscrites dans les objets, ni les logiciels qui les lisent. Les responsables de Git pouvaient choisir la destination. Chaque service distant et chaque outil dépendant de l’ancien format possédait une partie du trajet. Le dossier de 2018 montrait le pont souhaité; le manuel de 2026 indiquait encore la rive sur laquelle s’arrêtait l’échange ordinaire.

Dans un système adressé par son contenu, le nom est une pièce du mécanisme, et le mécanisme ne migre pas par communiqué.