Změny provedené na Github nebyly podle očekávání
Nedávno to bylo oznámeno GitHub změnil způsob generování souborů Automaticky generované ".tar.gz" a ".tgz" na spouštěcích stránkách.
Tato změna způsobily změny kontrolních součtů a masivní pády v systémech sestavení automatizované, které ověřují integritu souborů stažených z GitHubu oproti dříve uloženým kontrolním součtům, jako jsou ty, které jsou umístěny v metadatech balíčků nebo skriptech sestavení.
Od verze 2.38, Git, zahrnuto ve výchozím nastavení integrovaná implementace gzip, To umožnilo sjednotit podporu této kompresní metody napříč všemi operačními systémy a zlepšit výkon při vytváření souborů. GitHub zachytil změnu po upgradu verze git na jejich infrastruktuře.
Výchozí komprese souborů Git se nedávno změnila. V důsledku toho mohou mít soubory stažené z GitHubu různé kontrolní součty, i když se obsah úplně nezměnil.
GitHub nezaručuje stabilitu kontrolních součtů pro automaticky generované soubory. Ty jsou označeny slovy „Zdrojový kód (zip)“ a „Zdrojový kód (tar.gz)“ na kartě Verze. Pokud se potřebujete spolehnout na konzistentní kontrolní součet, můžete soubory nahrávat přímo do vydání GitHub.
Ty se zaručeně nezmění.
Problém byl než soubory generované tablety implementací gzip zlib build jsou různé binární soubory souborů generovaných obslužným programem gzip, což má za následek různé kontrolní součty pro archivy vytvořené různými verzemi git při spuštění příkazu "git archive".
Následně po aktualizaci git na GitHubu, se na stránkách vydání začaly objevovat trochu jiné soubory které se nepodařilo ověřit pomocí výše uvedených kontrolních součtů.
Problém se projevil v různých sestavovacích systémech, systémech průběžné integrace a sadách nástrojů pro sestavování balíčků ze zdroje. Například bylo rozbito asi 5800 portů FreeBSD, jejichž zdroje byly staženy z GitHubu.
V odpověď na první stížnosti na selhání, Zástupci GitHubu zpočátku poznamenali, že kontrolní součty nebyly nikdy zaručeny konstanty pro soubory.
Poté, co se ukázalo, že vytváření systémů sestavení ovlivněných změnou bude vyžadovat značné množství práce na aktualizaci metadat napříč různými ekosystémy, GitHub změnil názor, vrátil změnu a vrátil se ke staré metodě generování souborů.
Jak se očekávalo, lidé si začali stěžovat. První odpověď od zaměstnance GitHubu (a hlavního přispěvatele Git) briana m. Carlson tomu nerozuměl úplně:
Říkám, že politika nebyla nikdy správná a nikdy jsme nezaručili stabilní kontrolní součty pro soubory, stejně jako to Git nikdy nezaručil. Omlouvám se za to, že zde věci nefungují a v minulosti o tom nebyla srozumitelnější komunikace, ale naše zásady se za více než 4 roky nezměnily.
Vývojáři Git zatím se nerozhodli a pouze projednávají možné kroky. the Zvažované možnosti zahrnují použití nástroje gzip výchozí; přidání příznaku „–stable“ pro zachování kompatibility se staršími soubory; propojit vestavěnou implementaci se samostatným formátem souboru; použití nástroje gzip pro staré odevzdání a vestavěnou implementaci pro odevzdání od určitého data; zaručující stabilitu formátu pouze pro nekomprimované soubory.
Složitost rozhodnutí je vysvětlena skutečností, že návrat k externímu volání obslužného programu zcela nevyřeší problém invariance kontrolního součtu, protože změna v externím programu gzip může také způsobit změnu souboru.
V současné době existuje sada oprav ke kontrole, která se vrací k výchozímu chování (vyvolání externího nástroje gzip) a používá vestavěnou implementaci, když nástroj gzip není v systému přítomen. Záplaty také přidávají do dokumentace poznámku, že není zaručeno, že výstup "git archive" bude stabilní a že formát se v budoucnu může změnit.
Konečně pokud máte zájem o tom vědět více, můžete zkontrolovat podrobnosti v následující odkaz.