GitHub ändrade sättet att generera automatiskt genererade ".tar.gz" och ".tgz"-arkiv på releasesidor, vilket ledde till ändringar i deras kontrollsummor och massiva fel i automatiserade byggsystem som kontrollerar arkiv som laddats ner från GitHub mot tidigare för att bekräfta integriteten lagrade kontrollsummor, till exempel, placerade i paketmetadata eller i byggskript.
Från och med release 2.38 inkluderade Git-verktygslådan en inbyggd implementering av gzip som standard, vilket gjorde det möjligt att förena stödet för denna komprimeringsmetod över operativsystem och förbättra prestanda för skapande av arkiv. GitHub tog upp ändringen efter att ha uppdaterat versionen av git i dess infrastruktur. Problemet orsakades av det faktum att de komprimerade arkiven som genereras av den inbyggda zlib-baserade gzip-implementeringen skiljer sig binära från de arkiv som skapats av gzip-verktyget, vilket resulterade i olika kontrollsummor för arkiv skapade av olika versioner av git när du körde kommandot "git archive".
Följaktligen, efter att ha uppdaterat git i GitHub, började lite olika arkiv visas på utgivningssidorna, som inte klarade verifieringen med de gamla kontrollsummorna. Problemet visade sig i olika byggsystem, kontinuerliga integrationssystem och verktyg för att bygga paket från källkod. Till exempel bröts sammansättningen av cirka 5800 FreeBSD-portar, vars källkoder laddades ner från GitHub.
Som svar på initiala klagomål om felen citerade GitHub initialt det faktum att permanenta kontrollsummor för arkiv aldrig garanterades. Efter att det visat sig att en enorm mängd arbete skulle krävas för att uppdatera metadata i olika ekosystem för att återställa funktionaliteten hos de berörda byggsystemen, ändrade GitHub-representanter åsikt, återställde ändringen och returnerade den gamla metoden att generera arkiv.
Git-utvecklarna har ännu inte kommit till ett beslut och diskuterar bara möjliga åtgärder. Alternativ som övervägdes var att återgå till att använda standardverktyget gzip; lägga till flaggan "--stable" för att upprätthålla kompatibilitet med gamla arkiv; länka den inbyggda implementeringen till ett separat arkivformat; använda gzip-verktyget för gamla commits och inline-implementeringen för commits som börjar från ett visst datum; garanterar formatstabilitet endast för okomprimerade arkiv.
Svårigheten att fatta ett beslut förklaras av det faktum att återgång till ett anrop till ett externt verktyg inte helt löser problemet med oföränderlighet i checksumman, eftersom en förändring i det externa gzip-programmet också kan leda till en förändring av arkivformatet. För närvarande har en uppsättning patchar föreslagits för granskning som returnerar det gamla beteendet som standard (anropar ett externt gzip-verktyg) och använder den inbyggda implementeringen i frånvaro av ett gzip-verktyg i systemet. Patcharna lägger också till i dokumentationen ett omnämnande att stabiliteten för "git archive"-utgången inte är garanterad och formatet kan ändras i framtiden.
Källa: opennet.ru