GitHub zmienił sposób generowania automatycznie generowanych archiwów „.tar.gz” i „.tgz” na stronach wydań, co doprowadziło do zmian w ich sumach kontrolnych i ogromnych błędów w automatycznych systemach kompilacji, które sprawdzają archiwa pobrane z GitHub względem poprzednich, aby potwierdzić integralność przechowywane sumy kontrolne, na przykład umieszczane w metadanych pakietu lub w skryptach kompilacji.
Począwszy od wersji 2.38, zestaw narzędzi Git zawierał domyślnie wbudowaną implementację gzip, co umożliwiło ujednolicenie obsługi tej metody kompresji w różnych systemach operacyjnych i poprawę wydajności tworzenia archiwów. GitHub zauważył tę zmianę po zaktualizowaniu wersji git w swojej infrastrukturze. Problem wynikał z faktu, że skompresowane archiwa wygenerowane przez wbudowaną implementację gzip opartą na zlib różnią się binarnie od archiwów utworzonych przez narzędzie gzip, co skutkowało różnymi sumami kontrolnymi dla archiwów tworzonych przez różne wersje git podczas wykonywania polecenie „archiwum git”.
W związku z tym po aktualizacji git w GitHub na stronach wydań zaczęły pojawiać się nieco inne archiwa, które nie przeszły weryfikacji przy użyciu starych sum kontrolnych. Problem objawiał się różnymi systemami kompilacji, systemami ciągłej integracji i narzędziami do budowania pakietów z kodu źródłowego. Na przykład uszkodzony został zespół około 5800 portów FreeBSD, których kody źródłowe zostały pobrane z GitHuba.
W odpowiedzi na początkowe skargi dotyczące usterek GitHub początkowo powołał się na fakt, że nigdy nie gwarantowano stałych sum kontrolnych dla archiwów. Po tym, jak wykazano, że aktualizacja metadanych w różnych ekosystemach w celu przywrócenia funkcjonalności dotkniętych systemów kompilacji wymagałaby ogromnej pracy, przedstawiciele GitHuba zmienili zdanie, cofnęli zmianę i przywrócili starą metodę generowania archiwów.
Twórcy Gita nie podjęli jeszcze decyzji i dyskutują jedynie o możliwych działaniach. Rozważane opcje obejmowały powrót do korzystania z domyślnego narzędzia gzip; dodanie flagi „--stable” w celu zachowania kompatybilności ze starymi archiwami; powiązanie wbudowanej implementacji z oddzielnym formatem archiwum; używanie narzędzia gzip do starych zatwierdzeń i implementacja inline dla zatwierdzeń rozpoczynających się od określonej daty; gwarantując stabilność formatu tylko dla nieskompresowanych archiwów.
Trudność w podjęciu decyzji tłumaczy się faktem, że wycofanie połączenia z zewnętrznym narzędziem nie rozwiązuje całkowicie problemu niezmienności sumy kontrolnej, ponieważ zmiana w zewnętrznym programie gzip może również prowadzić do zmiany formatu archiwum. Obecnie do przeglądu zaproponowano zestaw poprawek, które domyślnie przywracają stare zachowanie (wywołanie zewnętrznego narzędzia gzip) i wykorzystują wbudowaną implementację w przypadku braku narzędzia gzip w systemie. Łatki dodają również do dokumentacji wzmiankę, że stabilność danych wyjściowych „archiwum git” nie jest gwarantowana, a format może ulec zmianie w przyszłości.
Źródło: opennet.ru