GitHub a modifié la façon dont il génère automatiquement les archives « .tar.gz » et « .tgz » sur les pages de version, ce qui a entraîné des modifications de leurs sommes de contrôle et des échecs massifs dans les systèmes de construction automatisés qui vérifient les archives téléchargées depuis GitHub par rapport aux précédentes pour confirmer l'intégrité. .sommes de contrôle stockées, par exemple placées dans les métadonnées du package ou dans les scripts de build.
À partir de la version 2.38, la boîte à outils Git incluait une implémentation intégrée de gzip par défaut, ce qui a permis d'unifier la prise en charge de cette méthode de compression sur tous les systèmes d'exploitation et d'améliorer les performances de création d'archives. GitHub a récupéré le changement après avoir mis à jour la version de git dans son infrastructure. Le problème était dû au fait que les archives compressées générées par l'implémentation gzip intégrée basée sur zlib sont binairement différentes des archives créées par l'utilitaire gzip, ce qui entraînait des sommes de contrôle différentes pour les archives créées par différentes versions de git lors de l'exécution de l'utilitaire gzip. Commande "archive git".
En conséquence, après la mise à jour de git dans GitHub, des archives légèrement différentes ont commencé à s'afficher sur les pages de version, qui n'ont pas réussi la vérification à l'aide des anciennes sommes de contrôle. Le problème s'est manifesté dans divers systèmes de construction, systèmes d'intégration continue et outils permettant de créer des packages à partir du code source. Par exemple, l'assemblage d'environ 5800 XNUMX ports FreeBSD, dont les codes sources ont été téléchargés depuis GitHub, a été interrompu.
En réponse aux premières plaintes concernant les problèmes, GitHub a initialement cité le fait que les sommes de contrôle permanentes des archives n'étaient jamais garanties. Après avoir démontré qu'une énorme quantité de travail serait nécessaire pour mettre à jour les métadonnées dans divers écosystèmes afin de restaurer la fonctionnalité des systèmes de build concernés, les représentants de GitHub ont changé d'avis, ont annulé la modification et ont renvoyé l'ancienne méthode de génération d'archives.
Les développeurs de Git n'ont pas encore pris de décision et discutent seulement des actions possibles. Les options envisagées comprenaient le retour à l'utilisation de l'utilitaire gzip par défaut ; ajout de l'indicateur « --stable » pour maintenir la compatibilité avec les anciennes archives ; relier l'implémentation intégrée à un format d'archive distinct ; en utilisant l'utilitaire gzip pour les anciens commits et l'implémentation en ligne pour les commits à partir d'une certaine date ; garantissant la stabilité du format uniquement pour les archives non compressées.
La difficulté de prendre une décision s'explique par le fait que revenir à un appel à un utilitaire externe ne résout pas complètement le problème de l'immuabilité de la somme de contrôle, puisqu'une modification du programme gzip externe peut également entraîner une modification du format d'archive. Actuellement, un ensemble de correctifs a été proposé pour révision, qui renvoie l'ancien comportement par défaut (appel d'un utilitaire gzip externe) et utilise l'implémentation intégrée en l'absence d'utilitaire gzip dans le système. Les correctifs ajoutent également à la documentation une mention selon laquelle la stabilité de la sortie "git archive" n'est pas garantie et que le format peut changer à l'avenir.
Source: opennet.ru