GitHub ændrede den måde, den genererer automatisk genererede ".tar.gz" og ".tgz"-arkiver på udgivelsessider, hvilket førte til ændringer i deres kontrolsummer og massive fejl i automatiserede byggesystemer, der kontrollerer arkiver downloadet fra GitHub mod tidligere for at bekræfte integriteten lagrede kontrolsummer, for eksempel placeret i pakkemetadata eller i build-scripts.
Startende med udgivelse 2.38 inkluderede Git-værktøjssættet en indbygget implementering af gzip som standard, hvilket gjorde det muligt at forene understøttelsen af denne komprimeringsmetode på tværs af operativsystemer og forbedre ydeevnen til oprettelse af arkiver. GitHub opfangede ændringen efter at have opdateret versionen af git i dens infrastruktur. Problemet var forårsaget af det faktum, at de komprimerede arkiver genereret af den indbyggede zlib-baserede gzip-implementering er binære forskellige fra de arkiver, der er oprettet af gzip-værktøjet, hvilket resulterede i forskellige kontrolsummer for arkiver oprettet af forskellige versioner af git, når du udfører "git archive" kommando.
Følgelig, efter opdatering af git i GitHub, begyndte der at blive vist lidt forskellige arkiver på udgivelsessiderne, som ikke bestod verifikation ved hjælp af de gamle kontrolsummer. Problemet manifesterede sig i forskellige byggesystemer, kontinuerlige integrationssystemer og værktøjer til at bygge pakker fra kildekode. For eksempel var samlingen af omkring 5800 FreeBSD-porte, hvortil kildekoderne blev downloadet fra GitHub, brudt.
Som svar på indledende klager over fejlene citerede GitHub oprindeligt det faktum, at permanente kontrolsummer for arkiver aldrig blev garanteret. Efter det blev vist, at der ville kræves en enorm mængde arbejde for at opdatere metadataene i forskellige økosystemer for at genoprette funktionaliteten af de berørte byggesystemer, ændrede GitHub-repræsentanter mening, vendte ændringen tilbage og returnerede den gamle metode til at generere arkiver.
Git-udviklerne har endnu ikke truffet en beslutning og diskuterer kun mulige handlinger. De overvejede muligheder omfattede at vende tilbage til at bruge standardværktøjet gzip; tilføjelse af "--stable"-flaget for at opretholde kompatibilitet med gamle arkiver; at forbinde den indbyggede implementering til et separat arkivformat; brug af gzip-værktøjet til gamle commits og inline-implementeringen til commits, der starter fra en bestemt dato; garanterer kun formatstabilitet for ukomprimerede arkiver.
Vanskeligheden ved at træffe en beslutning forklares med, at tilbagevenden til et opkald til et eksternt hjælpeprogram ikke helt løser problemet med checksum-ummutabilitet, da en ændring i det eksterne gzip-program også kan føre til en ændring i arkivformatet. I øjeblikket er et sæt patches blevet foreslået til gennemgang, der returnerer den gamle adfærd som standard (kalder et eksternt gzip-værktøj) og bruger den indbyggede implementering i fravær af et gzip-værktøj i systemet. Patcherne tilføjer også dokumentationen en omtale, at stabiliteten af "git archive"-outputtet ikke er garanteret, og formatet kan ændre sig i fremtiden.
Kilde: opennet.ru