GitHub änderte die Art und Weise, wie es automatisch generierte „.tar.gz“- und „.tgz“-Archive auf Release-Seiten generiert, was zu Änderungen in ihren Prüfsummen und massiven Fehlern in automatisierten Build-Systemen führte, die von GitHub heruntergeladene Archive mit früheren Archiven vergleichen, um ihre Integrität zu bestätigen . gespeicherte Prüfsummen, die beispielsweise in Paketmetadaten oder in Build-Skripten platziert werden.
Ab Version 2.38 enthielt das Git-Toolkit standardmäßig eine integrierte Implementierung von gzip, die es ermöglichte, die Unterstützung dieser Komprimierungsmethode auf allen Betriebssystemen zu vereinheitlichen und die Leistung bei der Archiverstellung zu verbessern. GitHub hat die Änderung übernommen, nachdem die Git-Version in seiner Infrastruktur aktualisiert wurde. Das Problem wurde durch die Tatsache verursacht, dass die von der integrierten zlib-basierten gzip-Implementierung generierten komprimierten Archive binär sind und sich von den vom gzip-Dienstprogramm erstellten Archiven unterscheiden, was zu unterschiedlichen Prüfsummen für Archive führte, die von verschiedenen Git-Versionen beim Ausführen erstellt wurden Befehl „git archive“.
Dementsprechend wurden nach der Aktualisierung von Git in GitHub leicht unterschiedliche Archive auf den Release-Seiten angezeigt, die die Überprüfung mit den alten Prüfsummen nicht bestanden haben. Das Problem manifestierte sich in verschiedenen Build-Systemen, kontinuierlichen Integrationssystemen und Tools zum Erstellen von Paketen aus Quellcode. Beispielsweise war die Zusammenstellung von etwa 5800 FreeBSD-Ports, deren Quellcodes von GitHub heruntergeladen wurden, kaputt.
Als Reaktion auf erste Beschwerden über die Pannen verwies GitHub zunächst darauf, dass dauerhafte Prüfsummen für Archive nie garantiert seien. Nachdem sich herausstellte, dass ein enormer Arbeitsaufwand erforderlich wäre, um die Metadaten in verschiedenen Ökosystemen zu aktualisieren, um die Funktionalität der betroffenen Build-Systeme wiederherzustellen, änderten GitHub-Vertreter ihre Meinung, machten die Änderung rückgängig und kehrten zur alten Methode der Archivgenerierung zurück.
Die Git-Entwickler haben sich noch nicht entschieden und diskutieren lediglich mögliche Maßnahmen. Zu den in Betracht gezogenen Optionen gehörte die Rückkehr zur Verwendung des Standarddienstprogramms gzip; Hinzufügen des Flags „--stable“, um die Kompatibilität mit alten Archiven aufrechtzuerhalten; Verknüpfen der integrierten Implementierung mit einem separaten Archivformat; Verwenden des gzip-Dienstprogramms für alte Commits und der Inline-Implementierung für Commits ab einem bestimmten Datum; Gewährleistung der Formatstabilität nur für unkomprimierte Archive.
Die Schwierigkeit, eine Entscheidung zu treffen, erklärt sich aus der Tatsache, dass ein Rollback auf einen Aufruf eines externen Dienstprogramms das Problem der Unveränderlichkeit der Prüfsumme nicht vollständig löst, da eine Änderung im externen gzip-Programm auch zu einer Änderung des Archivformats führen kann. Derzeit wurde eine Reihe von Patches zur Überprüfung vorgeschlagen, die standardmäßig das alte Verhalten zurückgeben (Aufruf eines externen gzip-Dienstprogramms) und die integrierte Implementierung verwenden, wenn im System kein gzip-Dienstprogramm vorhanden ist. Die Patches fügen der Dokumentation auch den Hinweis hinzu, dass die Stabilität der „Git-Archiv“-Ausgabe nicht garantiert ist und sich das Format in Zukunft ändern kann.
Source: opennet.ru