GitHub hat die Methode zur Erstellung automatisch generierter Archive im Format «.tar.gz» und «.tgz» auf den Release-Seiten geändert. Dies führte zu Veränderungen in den Prüfziffern und zu massiven Ausfällen in automatisierten Build-Systemen, die zur Überprüfung der Integrität die heruntergeladenen Archive von GitHub mit zuvor gespeicherten Prüfziffern, beispielsweise in den Metadaten von Paketen oder in Build-Skripten, abgleichen.
Ab Version 2.38 wurde in das Git-Toolkit standardmäßig eine integrierte gzip-Implementierung aufgenommen, die eine einheitliche Unterstützung dieser Komprimierungsmethode auf verschiedenen Betriebssystemen ermöglichte und die Leistung der Archivierung verbesserte. GitHub hat die Änderung nach dem Update der Git-Version in seiner Infrastruktur übernommen. Das Problem entstand dadurch, dass die komprimierten Archive, die von der integrierten gzip-Implementierung auf Basis von zlib generiert wurden, binär von Archiven abweichen, die mit dem gzip-Tool erstellt wurden. Dies führte zu unterschiedlichen Prüfziffern für Archive, die mit verschiedenen Git-Versionen beim Ausführen des Befehls «git archive» erstellt wurden.
Nach dem Update von Git auf GitHub wurden auf den Release-Seiten etwas andere Archive bereitgestellt, die nicht mit den alten Prüfziffern übereinstimmten. Dieses Problem trat in verschiedenen Build-Systemen, kontinuierlichen Integrationssystemen und in Paket-Build-Tools auf. Zum Beispiel scheiterte der Build von etwa 5800 FreeBSD-Paketen, deren Quelltexte von GitHub heruntergeladen wurden.
Als Reaktion auf die ersten Beschwerden über die aufgetretenen Fehler wiesen die Vertreter von GitHub zunächst darauf hin, dass für Archive keine permanenten Prüfziffern garantiert werden. Nachdem jedoch aufgezeigt wurde, dass zur Wiederherstellung der Funktionsfähigkeit der betroffenen Build-Systeme erhebliche Anstrengungen erforderlich sind, um die Metadaten in verschiedenen Ökosystemen zu aktualisieren, änderten die Vertreter von GitHub ihre Meinung, hoben die Änderung auf und stellten das alte Verfahren zur Archivgenerierung wieder her.
Die Entwickler von Git haben bisher keine Entscheidung getroffen und diskutieren lediglich mögliche Maßnahmen. Es wurden Optionen in Betracht gezogen wie die Rückkehr zur Verwendung des gzip-Utilities als Standard, das Hinzufügen eines Flags «—stable» zur Wahrung der Kompatibilität mit alten Archiven, die Bindung der integrierten Implementierung an ein separates Archivformat sowie die Verwendung des gzip für alte Commits und der integrierten Implementierung für Commits ab einem bestimmten Datum; die Garantie der Stabilität des Formats gilt nur für unkomprimierte Archive.
Die Komplexität der Entscheidungsfindung erklärt sich daraus, dass die Rückkehr zum Aufruf des externen Utilities 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 wurde ein Satz von Patches zum Überprüfen vorgeschlagen, der das alte Verhalten (den Aufruf des externen gzip-Utilities) als Standard zurückgibt und die integrierte Implementierung nutzt, wenn das gzip-Utility nicht im System vorhanden ist. Die Patches fügen auch in die Dokumentation die Erwähnung ein, dass die Stabilität der Ausgabe von «git archive» nicht garantiert werden kann und das Format in Zukunft geändert werden kann.
Quelle: opennet.ru
