GitHub změnil metodu vytváření automaticky generovaných archivů „.tar.gz“ a „.tgz“ na stránkách s vydáními, což vedlo ke změně jejich kontrolních součtů a masovým selháním v automatizovaných systémech sestavení, které pro ověření integrity provádějí kontrolu stahovaných archivů z GitHubu s dříve uloženými kontrolními součty, například umístěnými v metadatech balíčků nebo v sestavovacích skriptech.
Od verze 2.38 byla v nástrojích Git implicitně zahrnuta vestavěná implementace gzip, která umožnila unifikovat podporu této metody komprese v různých operačních systémech a zvýšit výkon vytváření archivů. GitHub převzal změnu po aktualizaci verze git ve své infrastruktuře. Problém vznikl proto, že komprimované archivy generované vestavěnou implementací gzip založenou na zlib se binárně liší od archivů vytvořených nástrojem gzip, což vedlo k odlišnému kontrolnímu součtu pro archivy vytvořené různými verzemi git při provádění příkazu „git archive“.
Po aktualizaci git na GitHubu se tedy na stránkách vydání začaly zpracovávat mírně jiné archivy, které neprocházely kontrolou podle starých kontrolních součtů. Problém se projevil v různých systémových sestavách, systémech kontinuální integrace a v nástrojích pro sestavení balíčků ze zdrojového kódu. Například byla narušena sestava přibližně 5800 portů FreeBSD, jejichž zdrojové kódy byly stahovány z GitHubu.
Na první stížnosti ohledně vzniklých selhání se zástupci GitHubu zpočátku odvolávali na to, že trvalé kontrolní součty pro archivy nikdy nebyly zaručeny. Po tom, co bylo prokázáno, že pro obnovení funkčnosti systémů sestavení, které byly změnou ovlivněny, bude potřeba kolosální práce na aktualizaci metadat v různých ekosystémech, zástupci GitHubu změnili svůj názor, zrušili změnu a vrátili starou metodu generování archivů.
Vývojáři Git dosud nedospěli k žádnému rozhodnutí a pouze diskutují o možných krocích. Zvažovaly se možnosti jako návrat k výchozímu použití nástroje gzip; přidání přepínače „—stable“ pro zachování kompatibility se starými archivy; propojení integrované implementace s odděleným formátem archivu; použití nástroje gzip pro staré commity a integrované implementace pro commity od určitého data; zaručení stability formátu pouze pro nekomprimované archivy.
Složitost rozhodování je způsobena tím, že návrat k volání externího nástroje zcela neřeší problém neměnnosti kontrolních součtů, protože změny v externím programu gzip mohou také vést ke změně formátu archivu. V současné době byl pro přezkoumání navržen soubor patchů, který vrací výchozí chování (volání externího nástroje gzip) a používá integrovanou implementaci v případě, že systém nemá nástroj gzip. Patche také přidávají do dokumentace zmínku, že stabilita výstupu „git archive“ není zaručena a formát se může v budoucnu změnit.
Zdroj: opennet.ru
