GitHub endret måten den genererer automatisk genererte ".tar.gz" og ".tgz"-arkiver på utgivelsessider, noe som førte til endringer i sjekksummene og massive feil i automatiserte byggesystemer som sjekker arkiver lastet ned fra GitHub mot tidligere for å bekrefte integriteten lagrede sjekksummer, for eksempel plassert i pakkemetadata eller i byggeskript.
Fra og med versjon 2.38 inkluderte Git-verktøysettet en innebygd implementering av gzip som standard, som gjorde det mulig å forene støtte for denne komprimeringsmetoden på tvers av operativsystemer og forbedre ytelsen til arkivoppretting. GitHub plukket opp endringen etter å ha oppdatert versjonen av git i infrastrukturen. Problemet var forårsaket av det faktum at de komprimerte arkivene generert av den innebygde zlib-baserte gzip-implementeringen er binære forskjellige fra arkivene opprettet av gzip-verktøyet, noe som resulterte i forskjellige kontrollsummer for arkiver opprettet av forskjellige versjoner av git når du kjører "git archive" kommando.
Følgelig, etter oppdatering av git i GitHub, begynte litt forskjellige arkiver å bli vist på utgivelsessidene, som ikke besto verifiseringen med de gamle kontrollsummene. Problemet manifesterte seg i ulike byggesystemer, kontinuerlige integrasjonssystemer og verktøy for å bygge pakker fra kildekode. For eksempel ble samlingen av rundt 5800 FreeBSD-porter, kildekodene som ble lastet ned fra GitHub, ødelagt.
Som svar på innledende klager på feilene, siterte GitHub først det faktum at permanente kontrollsummer for arkiver aldri ble garantert. Etter at det ble vist at en enorm mengde arbeid ville kreves for å oppdatere metadataene i ulike økosystemer for å gjenopprette funksjonaliteten til de berørte byggesystemene, ombestemte GitHub-representanter seg, snudde endringen og returnerte den gamle metoden for å generere arkiver.
Git-utviklerne har ennå ikke tatt en avgjørelse og diskuterer bare mulige handlinger. Alternativer som ble vurdert inkluderte å gå tilbake til å bruke standard gzip-verktøy; legge til "--stable"-flagget for å opprettholde kompatibilitet med gamle arkiver; koble den innebygde implementeringen til et eget arkivformat; bruk av gzip-verktøyet for gamle commits og den innebygde implementeringen for commits som starter fra en bestemt dato; garanterer formatstabilitet kun for ukomprimerte arkiver.
Vanskeligheten med å ta en avgjørelse forklares av det faktum at å rulle tilbake til et anrop til et eksternt verktøy ikke helt løser problemet med sjekksum-ummutabilitet, siden en endring i det eksterne gzip-programmet også kan føre til en endring i arkivformatet. For øyeblikket har et sett med patcher blitt foreslått for gjennomgang som returnerer den gamle atferden som standard (kaller et eksternt gzip-verktøy) og bruker den innebygde implementeringen i fravær av et gzip-verktøy i systemet. Patchene legger også til dokumentasjonen en omtale at stabiliteten til "git archive"-utgangen ikke er garantert og formatet kan endres i fremtiden.
Kilde: opennet.ru