Fehler in den Build-Systemen aufgrund von Änderungen an den Prüfziffern der Archive in GitHub

GitHub hat die Methode zur Erstellung automatisch generierter Archive im Format „.tar.gz“ und „.tgz“ auf den Release-Seiten geändert, was zu Veränderungen der Prüfziffern und massiven Ausfällen in automatisierten Build-Systemen geführt hat, die zur Verifizierung der Integrität die heruntergeladenen Archive von GitHub mit zuvor gespeicherten Prüfziffern abgleichen, zum Beispiel die in den Metadaten von Paketen oder in Build-Skripten hinterlegt sind.

Seit dem Release 2.38 ist in das Git-Toolkit standardmäßig eine integrierte Gzip-Implementierung aufgenommen worden, die eine einheitliche Unterstützung dieser Komprimierungsmethode in verschiedenen Betriebssystemen ermöglicht und die Leistung bei der Erstellung von Archiven verbessert. GitHub hat die Änderung nach dem Upgrade der Git-Version in seiner Infrastruktur aufgegriffen. Das Problem entstand, weil die komprimierten Archive, die von der integrierten Gzip-Implementierung auf Basis von zlib generiert wurden, binär von den Archiven abweichen, die mit dem Tool Gzip erstellt wurden, was zu unterschiedlichen Prüfziffern für Archive führt, die mit verschiedenen Git-Versionen beim Ausführen des Befehls „git archive“ erstellt wurden.

Nach dem Upgrade von Git auf GitHub wurden folglich auf den Release-Seiten etwas andere Archive bereitgestellt, die nicht mit den alten Prüfziffern übereinstimmten. Das Problem trat in verschiedenen Build-Systemen, Continuous Integration-Systemen und in den Werkzeugen zur Erstellung von Paketen aus Quelltexten auf. Beispielsweise wurde der Build von etwa 5800 FreeBSD-Paketen, deren Quelltexte von GitHub heruntergeladen wurden, beeinträchtigt.

Als Reaktion auf die ersten Beschwerden über die aufgetretenen Ausfälle verwiesen die Vertreter von GitHub zunächst darauf, dass feste Prüfziffern für Archive niemals garantiert worden seien. Nachdem jedoch aufgezeigt wurde, dass zur Wiederherstellung des Betriebs der von der Änderung betroffenen Build-Systeme eine enorme Arbeit zur Aktualisierung der Metadaten in verschiedenen Ökosystemen erforderlich sein würde, änderten die Vertreter von GitHub ihre Meinung, hoben die Änderung auf und stellten die alte Methode zur Erstellung von Archiven wieder her.

Die Git-Entwickler haben bisher keine Lösung gefunden und diskutieren lediglich mögliche Schritte. Es wurden Optionen wie ein Rollback zur Verwendung des gzip-Tools als Standard, die Hinzufügung eines Flags «—stable», um die Kompatibilität mit alten Archiven zu gewährleisten, die Bindung der integrierten Implementierung an ein bestimmtes Archivformat, die Verwendung des gzip-Tools für alte Commits und der integrierten Implementierung für Commits ab einem bestimmten Datum, sowie die Gewährleistung der Stabilität des Formats nur für unkomprimierte Archive in Betracht gezogen.

Die Schwierigkeiten bei der Entscheidungsfindung ergeben sich daraus, dass ein Rollback zur Verwendung eines externen Tools das Problem der Unveränderlichkeit der Prüfziffern nicht vollständig löst, da Änderungen im externen Programm gzip ebenfalls zu Änderungen im Archivformat führen können. Derzeit liegt ein Satz von Patches zur Überprüfung vor, der das alte Verhalten (Aufruf des externen gzip-Tools) als Standard wiederherstellt und die integrierte Implementierung verwendet, wenn das gzip-Tool nicht im System vorhanden ist. Die Patches fügen außerdem in die Dokumentation einen Hinweis ein, dass die Stabilität der Ausgabe von „git archive“ nicht garantiert werden kann und das Format in Zukunft geändert werden könnte.

Quelle: opennet.ru