GitHub a changé la méthode de génération des archives automatiquement créées en «.tar.gz» et «.tgz» sur les pages de versions, ce qui a entraîné un changement de leurs sommes de contrôle et des défaillances massives dans les systèmes de construction automatisés qui, pour vérifier l'intégrité, comparent les archives téléchargées depuis GitHub avec des sommes de contrôle précédemment sauvegardées, par exemple, celles indiquées dans les métadonnées des paquets ou dans les scripts de construction.
À partir de la version 2.38, un module gzip intégré a été inclus par défaut dans l'outil Git, ce qui a permis d'unifier la prise en charge de cette méthode de compression sur différents systèmes d'exploitation et d'améliorer les performances de création des archives. GitHub a adopté ce changement après la mise à jour de la version de git dans son infrastructure. Le problème vient du fait que les archives compressées créées par la version intégrée de gzip basée sur zlib diffèrent binaires des archives créées par l'utilitaire gzip, ce qui a conduit à des sommes de contrôle différentes pour les archives créées par différentes versions de git lors de l'exécution de la commande «git archive».
En conséquence, après la mise à jour de git sur GitHub, des archives légèrement différentes ont commencé à être fournies sur les pages de versions, ne passant pas la vérification avec les 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 de construction de paquets à partir de fichiers sources. Par exemple, la construction d'environ 5800 ports FreeBSD a été interrompue, les fichiers sources étant téléchargés depuis GitHub.
En réponse aux premières plaintes concernant les défaillances, les représentants de GitHub ont d'abord affirmé que les sommes de contrôle permanentes pour les archives n'étaient jamais garanties. Après qu'il a été montré que le rétablissement du fonctionnement des systèmes de construction affectés par le changement nécessiterait un travail colossal de mise à jour des métadonnées dans différents écosystèmes, les représentants de GitHub ont changé d'avis, ont annulé la modification et sont revenus à l'ancienne méthode de génération des archives.
Les développeurs de Git n'ont pas encore trouvé de solution et discutent uniquement des actions possibles. Des options telles que le retour à l'utilisation de l'outil gzip par défaut, l'ajout d'un drapeau « —stable » pour maintenir la compatibilité avec les anciens archives, l'attachement d'une implémentation intégrée à un format d'archive spécifique, l'utilisation de l'outil gzip pour les anciens commits et d'une implémentation intégrée pour les commits à partir d'une certaine date, ainsi que la garantie de la stabilité du format uniquement pour les archives non compressées ont été envisagées.
La complexité de la prise de décision s'explique par le fait que le retour à l'appel d'un utilitaire externe ne résout pas complètement le problème d'immutabilité des sommes de contrôle, car un changement dans le programme externe gzip peut également entraîner un changement dans le format d'archive. Actuellement, un ensemble de correctifs a été proposé pour revenir au comportement ancien par défaut (appel de l'utilitaire externe gzip) et pour utiliser une implémentation intégrée en l'absence de l'outil gzip sur le système. Les correctifs ajoutent également une mention dans la documentation indiquant que la stabilité de la sortie « git archive » n'est pas garantie et que le format peut être modifié à l'avenir.
Source : opennet.ru
