Les changements apportés sur Github n'ont pas été comme prévu
Il a été récemment signalé que GitHub a modifié la méthode de génération automatique des fichiers « .tar.gz » et « .tgz » sur les pages de publication.
Cette modification a entraîné des changements dans les sommes de contrôle et des défaillances massives dans les systèmes de compilation automatisés, qui vérifient l'intégrité des fichiers téléchargés depuis GitHub par rapport aux sommes de contrôle précédemment stockées, telles que celles placées dans les métadonnées des packages ou les scripts de compilation.
À partir de la version 2.38, Git intègre par défaut une implémentation de gzip, uniformisant ainsi la compatibilité avec cette méthode de compression sur tous les systèmes d'exploitation et améliorant les performances de création de fichiers. GitHub a adopté cette modification après la mise à jour de la version de Git sur son infrastructure.
La compression par défaut des fichiers Git a récemment changé. Par conséquent, les fichiers téléchargés depuis GitHub peuvent avoir des sommes de contrôle différentes même si le contenu n'a pas complètement changé.
GitHub ne garantit pas la stabilité des sommes de contrôle pour les fichiers générés automatiquement. Ceux-ci sont marqués par les mots "Code source (zip)" et "Code source (tar.gz)" dans l'onglet Versions. Si vous devez vous fier à une somme de contrôle cohérente, vous pouvez télécharger des fichiers directement sur GitHub Releases.
Ceux-ci sont garantis de ne pas changer.
Le problème était que les fichiers compressés générés par l'implémentation gzip intégrée de zlib sont des binaires différents des fichiers générés par l'utilitaire gzip, ce qui entraîne des sommes de contrôle différentes pour les fichiers créés par différentes versions de git lors de l'exécution de la commande « git archive ».
Par conséquent, après la mise à jour de git sur GitHub , des fichiers légèrement différents ont commencé à apparaître sur les pages de publication, fichiers qui n'ont pas pu être vérifiés avec les sommes de contrôle précédentes.
Le problème s'est manifesté dans divers systèmes de construction, systèmes d'intégration continue et boîtes à outils pour créer des packages à partir de la source. Par exemple, environ 5800 ports de FreeBSD ont été cassés, dont les sources ont été téléchargées depuis GitHub.
En réponse aux premières plaintes concernant les défaillances, les représentants de GitHub ont d'abord souligné que la cohérence des sommes de contrôle des fichiers n'était jamais garantie.
Après avoir montré que la création de systèmes de construction affectés par le changement nécessiterait une quantité importante de travail pour mettre à jour les métadonnées dans les différents écosystèmes, GitHub a changé d'avis, annulant le changement et revenant à l'ancienne méthode de génération de fichiers. .
Comme prévu, les plaintes ont fusé . La première réaction de Brian M. Carlson, employé de GitHub (et principal contributeur à Git), fut loin d'être bienveillante :
Je dis que la politique n'a jamais été correcte et nous n'avons jamais garanti des sommes de contrôle stables pour les fichiers, tout comme Git ne l'a jamais garanti. Je m'excuse pour les choses qui ne fonctionnent pas ici et il n'y a pas eu de communication plus claire à ce sujet dans le passé, mais notre politique n'a pas changé depuis plus de 4 ans.
Les développeurs de Git n'ont pas encore pris de décision et discutent des actions possibles. Parmi les options envisagées : revenir à l' utilitaire gzip par défaut ; ajouter l'option `--stable` pour préserver la compatibilité avec les anciens fichiers ; lier l'implémentation intégrée à un format de fichier distinct ; utiliser gzip pour les anciens commits et l'implémentation intégrée pour les commits à partir d'une certaine date ; et garantir la stabilité du format uniquement pour les fichiers non compressés.
La complejidad de la decisión se explica por el hecho de que la reversión a la llamada de la utilidad externa no resuelve completamente el problema de la invariancia de las sumas de verificación, ya que un cambio en el programa gzip externo también puede provocar un cambio en l'archive.
Actuellement, il existe un ensemble de correctifs à examiner qui revient au comportement par défaut (appel d'un utilitaire gzip externe) et utilise l'implémentation intégrée lorsque l'utilitaire gzip n'est pas présent sur le système. Les correctifs ajoutent également une note à la documentation indiquant que la sortie de "git archive" n'est pas garantie d'être stable et que le format est susceptible de changer à l'avenir.
Enfin, si vous souhaitez en savoir plus à ce sujet , vous trouverez les détails en suivant ce lien.