Git 3.0 est bien plus qu'un simple numéro de version
Git 3.0 est en passe de devenir la première version majeure avec rupture de compatibilité pour le système de contrôle de version depuis la sortie de Git 2.0 en 2014. Bien qu'aucune date de sortie officielle n'ait été fixée, deux changements significatifs sont prévus qui impacteront les développeurs et l'infrastructure : Rust deviendra une dépendance de build obligatoire, et SHA-256 est prévu comme algorithme de hachage par défaut pour les nouveaux dépôts.
Le passage à Rust vise à améliorer la sécurité mémoire, en traitant une source courante de vulnérabilités de sécurité dans la base de code C de Git. Bien que les composants Rust aient été activés par défaut dans les récentes versions de Git 2.x, Git 3.0 supprimera l'option de les désactiver lors de la compilation, faisant de Rust un prérequis pour construire le logiciel.
Parallèlement, le projet prévoit de passer de SHA-1 à SHA-256 comme hachage par défaut pour les nouveaux dépôts. Ce changement fera passer les hashs de commit de 40 à 64 caractères, impactant les outils, scripts et pipelines d'Intégration Continue (CI) existants qui s'attendent au format plus court.
Il est crucial de distinguer les plans annoncés des logiciels publiés. Rust a été une option par défaut désactivable dans les versions Git 2.x, mais Git 3.0 n'est pas encore sorti. Les dépôts existants ne seront pas automatiquement convertis en SHA-256 ; le changement n'affectera que les dépôts nouvellement initialisés.
L'exigence Rust a un coût lié à la plateforme
Git 3.0 imposera la Rust toolchain pour la compilation, un changement motivé par des préoccupations de sécurité mémoire. Une partie significative des vulnérabilités de sécurité de Git provient historiquement de bugs de mémoire dans sa base de code C, incitant l'équipe principale à intégrer des composants Rust.
Cette exigence introduit des défis de compatibilité de plateforme. Le compilateur Rust et la toolchain associée ne prennent pas en charge toutes les plateformes Unix héritées ou propriétaires où Git se compile actuellement avec succès. Bien que Rust ait été une option par défaut désactivable dans les récentes versions de Git 2.x, Git 3.0 supprimera cette flexibilité.
Pour atténuer les perturbations immédiates, la version finale de Git 2.x bénéficiera d'un Support Long Terme (LTS) étendu. Cette disposition vise à donner aux équipes sur des plateformes non prises en charge du temps supplémentaire pour développer une stratégie à long terme pour leur infrastructure Git, car les mises à niveau continues nécessiteront un environnement de build compatible.
Pourquoi les hashs de 64 caractères pourraient se répercuter sur la CI
Git 3.0 étendra les ID d'objets de 40 à 64 caractères hexadécimaux, un passage de SHA-1 (160 bits) à SHA-256 (256 bits) pour les hashs. Ce changement, tout en améliorant la résistance aux collisions cryptographiques, entraîne une dette de compatibilité substantielle pour les workflows Git existants.
Des centaines de milliers de scripts internes, d'expressions régulières et de caches CI supposent actuellement une longueur de hash de 40 caractères. La mise à jour de ces systèmes nécessitera un effort d'ingénierie significatif au sein des organisations, affectant :
- Les pipelines CI/CD
- Les Git hooks
- Les outils tiers
- Les mécanismes de mise en cache internes
L'interopérabilité des dépôts présente un autre défi. Les dépôts SHA-256 ne peuvent pas intégrer de manière transparente des dépôts SHA-1 en tant que sous-modules sans implémenter des mécanismes de pontage spécifiques. Les plateformes d'hébergement doivent également mettre à jour leur infrastructure pour prendre en charge le nouveau format de hash, sous peine de voir les utilisateurs confrontés à des fonctionnalités limitées.
Le cofondateur de GitHub, Scott Chacon, a qualifié cette migration de « cauchemar mondial », arguant que les avantages pratiques en matière de sécurité sont minimes par rapport au coût pour l'ensemble de l'écosystème. Il souligne l'affirmation originale de Linus Torvalds en 2005 selon laquelle la sécurité de Git repose fondamentalement sur la confiance distribuée, et non uniquement sur des hachages résistants aux collisions. Pour en savoir plus sur les changements à venir, consultez la BreakingChanges Documentation - Git.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Le débat sur la sécurité — et ce qu'il faut tester maintenant
La transition vers SHA-256 a suscité un débat sur les avantages en matière de sécurité par rapport aux coûts de migration. Le cofondateur de GitHub, Scott Chacon, soutient que les gains de sécurité pratiques sont minimes, arguant que le modèle de sécurité de Git, tel que décrit par Linus Torvalds en 2005, repose principalement sur la confiance distribuée et le contrôle d'accès. Chacon suggère que compromettre les identifiants d'un dépôt ou manipuler un mainteneur par ingénierie sociale représente un vecteur d'attaque à moindre coût et à plus forte probabilité qu'une collision cryptographique.
Les mainteneurs rétorquent que les faiblesses connues de SHA-1, y compris les attaques par collision démontrées, nécessitent une préparation avant qu'une crise ne force la main. Bien que des hachages plus robustes ne traitent pas les identifiants compromis ou l'ingénierie sociale, l'intégrité cryptographique demeure une composante distincte et critique de la confiance dans un dépôt. Les ingénieurs Git de Google reconnaissent les défis mais avertissent que les collisions SHA-1 deviendront plus faciles, laissant l'industrie dans l'embarras si les changements sont retardés.
Les développeurs peuvent tester la compatibilité SHA-256 dès aujourd'hui en utilisant git init --object-format=sha256. Cette commande initialise les nouveaux dépôts avec le format SHA-256. Les dépôts existants ne seront pas convertis automatiquement et conserveront leur format d'objet SHA-1.
Les tests doivent se concentrer sur :
- Les pipelines d'intégration continue (CI)
- Les scripts d'automatisation
- La gestion des sous-modules
- La prise en charge de la nouvelle longueur de hachage par le système hôte
Ces vérifications proactives peuvent identifier les points de rupture potentiels dans toute la chaîne d'outils de développement.
Foire aux questions
Quels sont les changements majeurs prévus dans Git 3.0 ?
Git 3.0 devrait nécessiter Rust pour la compilation et faire de SHA-256 le format de hachage par défaut pour les dépôts nouvellement initialisés. La version n'a pas de date officielle.
Git 3.0 convertira-t-il mon dépôt existant en SHA-256 ?
Non. Les dépôts existants conservent leur format d'objet actuel ; le défaut SHA-256 prévu s'applique aux dépôts nouvellement initialisés.
Comment puis-je essayer un dépôt Git SHA-256 dès maintenant ?
Exécutez git init --object-format=sha256 pour initialiser un dépôt en utilisant SHA-256, sous réserve des limites de compatibilité de vos outils et de votre plateforme d'hébergement.
Pourquoi Rust devient-il une exigence de compilation pour Git ?
L'objectif déclaré est de réduire les risques liés à la sécurité mémoire dans Git. Le compromis est que certaines plateformes sans prise en charge de la chaîne d'outils Rust pourraient ne pas être en mesure de compiler Git 3.0.