GitHub har ændret metoden til automatisk genererede arkiver "tar.gz" og "tgz" på releasesiderne, hvilket har ført til ændringer i deres kontrolsummationer og massive fejlsituationer i automatiserede byggeprocesser, der bekræfter integriteten ved at sammenligne de downloadede arkiver fra GitHub med tidligere gemte kontrolsummationer, eksempelvis placeret i metadata for pakker eller i byggekoder.
Fra version 2.38 inkluderede Git værktøjet som standard en indbygget implementering af gzip, som gjorde det muligt at standardisere støtte til denne komprimeringsmetode på tværs af forskellige operativsystemer og forbedre ydelsen ved oprettelse af arkiver. GitHub tilpassede sig ændringen efter opdateringen af git-versionen i deres infrastruktur. Problemet opstod, fordi de komprimerede arkiver, der blev genereret af den indbyggede gzip-implementering baseret på zlib, binært adskiller sig fra arkiverne oprettet af gzip-værktøjet, hvilket førte til forskelle i kontrolsummationerne for arkiverne, der blev oprettet med forskellige versioner af git, når kommandoen "git archive" blev udført.
Som følge heraf blev der efter opdateringen af git på GitHub sendt lidt andre arkiver fra releasesiderne, som ikke bestod kontrollen med de gamle kontrolsummationer. Problemet viste sig i forskellige byggeprocesser, systemer til kontinuerlig integration og i værktøjer til bygning af pakker fra kildekoder. For eksempel blev opbygningen af cirka 5800 FreeBSD-ports forstyrret, hvis kildekoder blev downloadet fra GitHub.
Som svar på de første klager over de opståede fejl henviste repræsentanter fra GitHub i starten til, at permanente kontrolsummationer for arkiver aldrig var blevet garanteret. Efter at det blev vist, at det ville kræve en enorm indsats at opdatere metadata i forskellige økosystemer for at genoprette operabiliteten af de berørte byggeprocesser, ændrede repræsentanterne fra GitHub mening, annullerede ændringen og genoptog den gamle metode til at generere arkiver.
Git-udviklerne er endnu ikke blevet enige om en løsning og diskuterer blot mulige tiltag. Der overvejes muligheder som at gå tilbage til at bruge gzip-værktøjet som standard, tilføje flaget "—stable" for at bevare kompatibiliteten med gamle arkiver, knytte den indbyggede implementering til et separat arkivformat, bruge gzip-værktøjet til gamle commits og den indbyggede implementering til commits fra en bestemt dato, samt at garantere formatets stabilitet kun for ukomprimerede arkiver.
Besværet ved at træffe en beslutning skyldes, at tilbagevenden til kaldet til et eksternt værktøj ikke helt løser problemet med ukonstante kontrolsummen, da ændringer i det eksterne program gzip også kan føre til ændringer i arkivformatet. I øjeblikket er der foreslået et sæt patches til gennemgang, der genindfører den gamle adfærd som standard (kald til det eksterne gzip-værktøj) og bruger den indbyggede implementering ved fravær af gzip-værktøjet i systemet. Patches tilføjer også et notat til dokumentationen om, at stabiliteten af output fra "git archive" ikke er garanteret, og at formatet kan ændre sig i fremtiden.
Kilde: opennet.ru
