GitHub zmienił metodę tworzenia automatycznie generowanych archiwów „.tar.gz” i „.tgz” na stronach z wydaniami, co doprowadziło do zmiany ich sum kontrolnych i masowych awarii w zautomatyzowanych systemach kompilacji, które dla potwierdzenia integralności weryfikują pobrane archiwa z GitHub z wcześniej zapisanymi sumami kontrolnymi, na przykład umieszczonymi w metadanych pakietów lub w skryptach kompilacyjnych.
Począwszy od wydania 2.38 w narzędziu Git, domyślnie włączono wbudowaną implementację gzip, która pozwalała na ujednolicenie wsparcia dla tej metody kompresji w różnych systemach operacyjnych oraz zwiększenie wydajności tworzenia archiwów. GitHub wprowadził tę zmianę po aktualizacji wersji git w swojej infrastrukturze. Problem spowodowany był tym, że skompresowane archiwa generowane przez wbudowaną implementację gzip na bazie zlib różnią się binarnie od archiwów tworzonych przez narzędzie gzip, co prowadzi do różnic w sumach kontrolnych dla archiwów tworzonych przez różne wersje git podczas wykonywania polecenia „git archive”.
W związku z tym, po aktualizacji git w GitHub na stronach z wydaniami zaczęto przekazywać nieco inne archiwa, które nie przechodziły weryfikacji według starych sum kontrolnych. Problem objawił się w różnych systemach budowania, systemach ciągłej integracji oraz w narzędziach do budowy pakietów z kodu źródłowego. Na przykład, naruszono kompilację około 5800 portów FreeBSD, których kod źródłowy został pobrany z GitHub.
W odpowiedzi na pierwsze skargi dotyczące występujących awarii, przedstawiciele GitHub początkowo argumentowali, że stałe sumy kontrolne dla archiwów nigdy nie były gwarantowane. Po tym, jak wykazano, że przywrócenie funkcjonalności systemów kompilacji, na które wpłynęła zmiana, będzie wymagać kolosalnej pracy nad aktualizacją metadanych w różnych ekosystemach, przedstawiciele GitHub zmienili swoje zdanie, anulowali zmianę i przywrócili starą metodę generowania archiwów.
Programiści Git wciąż nie doszli do żadnego rozwiązania i jedynie dyskutują nad możliwymi działaniami. Rozważano takie opcje, jak powrót do domyślnego użycia narzędzia gzip; dodanie flagi „—stable” w celu zapewnienia zgodności ze starymi archiwami; powiązanie wbudowanej implementacji z oddzielnym formatem archiwum; użycie narzędzia gzip dla starych commitów oraz wbudowanej implementacji dla commitów od określonej daty; gwarantowanie stabilności formatu jedynie dla nieskompresowanych archiwów.
Trudność w podjęciu decyzji wynika z faktu, że przywrócenie wywołania zewnętrznego narzędzia nie rozwiązuje problemu niezmienności sum kontrolnych, ponieważ zmiana w zewnętrznym programie gzip również może prowadzić do zmiany formatu archiwum. Obecnie zaproponowano zestaw poprawek do recenzji, które przywracają domyślne zachowanie (wywołanie zewnętrznego narzędzia gzip) i wykorzystują wbudowaną implementację w przypadku braku narzędzia gzip w systemie. Poprawki te również dodają do dokumentacji wzmiankę, że stabilność outputu „git archive” nie jest gwarantowana, a format może ulec zmianie w przyszłości.
Źródło: opennet.ru
