GitHub změnil způsob, jakým generuje automaticky generované archivy „.tar.gz“ a „.tgz“ na stránkách vydání, což vedlo ke změnám jejich kontrolních součtů a masivním selháním v automatizovaných systémech sestavování, které porovnávají archivy stažené z GitHubu s předchozími, aby potvrdily integritu. uložené kontrolní součty, například umístěné v metadatech balíčku nebo ve skriptech sestavení.
Počínaje verzí 2.38 obsahovala sada nástrojů Git ve výchozím nastavení vestavěnou implementaci gzip, což umožnilo sjednotit podporu této metody komprese napříč operačními systémy a zlepšit výkon při vytváření archivů. GitHub zachytil změnu po aktualizaci verze git ve své infrastruktuře. Problém byl způsoben skutečností, že komprimované archivy generované vestavěnou implementací gzip založenou na zlib jsou binárně odlišné od archivů vytvořených obslužným programem gzip, což vedlo k různým kontrolním součtům pro archivy vytvořené různými verzemi git při spouštění příkaz "git archive".
V souladu s tím se po aktualizaci git v GitHubu na stránkách vydání začaly zobrazovat mírně odlišné archivy, které neprošly ověřením pomocí starých kontrolních součtů. Problém se projevil v různých sestavovacích systémech, systémech průběžné integrace a nástrojích pro sestavování balíčků ze zdrojového kódu. Například byla rozbita sestava asi 5800 portů FreeBSD, jejichž zdrojové kódy byly staženy z GitHubu.
V reakci na počáteční stížnosti na závady GitHub zpočátku citoval skutečnost, že trvalé kontrolní součty pro archivy nebyly nikdy zaručeny. Poté, co se ukázalo, že aktualizace metadat v různých ekosystémech bude vyžadovat obrovské množství práce, aby se obnovila funkčnost dotčených systémů sestavení, zástupci GitHubu změnili názor, změnu vrátili zpět a vrátili starou metodu generování archivů.
Vývojáři Gitu se zatím nerozhodli a pouze diskutují o možných akcích. Zvažované možnosti zahrnují návrat k použití výchozího nástroje gzip; přidání příznaku „--stable“ pro zachování kompatibility se starými archivy; propojení vestavěné implementace do samostatného archivního formátu; použití nástroje gzip pro staré odevzdání a inline implementaci pro odevzdání počínaje určitým datem; zaručující stabilitu formátu pouze pro nekomprimované archivy.
Obtížnost rozhodování je vysvětlena skutečností, že návrat k volání externího nástroje zcela nevyřeší problém neměnnosti kontrolního součtu, protože změna v externím programu gzip může také vést ke změně formátu archivu. Aktuálně byla ke kontrole navržena sada záplat, která ve výchozím nastavení vrací staré chování (volání externího nástroje gzip) a používá vestavěnou implementaci, pokud v systému není nástroj gzip. Záplaty také přidávají do dokumentace zmínku, že stabilita výstupu "git archivu" není zaručena a formát se může v budoucnu změnit.
Zdroj: opennet.ru