GitHub veranderde de manier waarop het automatisch gegenereerde β.tar.gzβ- en β.tgzβ-archieven genereert op releasepaginaβs, wat leidde tot veranderingen in hun checksums en enorme fouten in geautomatiseerde bouwsystemen die archieven gedownload van GitHub vergelijken met eerdere om de integriteit te bevestigen opgeslagen controlesommen, bijvoorbeeld geplaatst in pakketmetagegevens of in buildscripts.
Vanaf release 2.38 bevatte de Git-toolkit standaard een ingebouwde implementatie van gzip, wat het mogelijk maakte om de ondersteuning voor deze compressiemethode over verschillende besturingssystemen te verenigen en de prestaties bij het maken van archieven te verbeteren. GitHub heeft de verandering opgepikt na het updaten van de versie van git in zijn infrastructuur. Het probleem werd veroorzaakt door het feit dat de gecomprimeerde archieven gegenereerd door de ingebouwde op zlib gebaseerde gzip-implementatie binair verschillend zijn van de archieven gemaakt door het gzip-hulpprogramma, wat resulteerde in verschillende controlesommen voor archieven gemaakt door verschillende versies van git bij het uitvoeren van de "git archive"-opdracht.
Dienovereenkomstig werden er, na het updaten van git in GitHub, enigszins andere archieven weergegeven op de releasepagina's, die de verificatie met behulp van de oude checksums niet doorstonden. Het probleem manifesteerde zich in verschillende bouwsystemen, continue integratiesystemen en tools voor het bouwen van pakketten vanuit de broncode. De assemblage van ongeveer 5800 FreeBSD-poorten, waarvan de broncodes waren gedownload van GitHub, was bijvoorbeeld kapot.
In reactie op de eerste klachten over de problemen noemde GitHub aanvankelijk het feit dat permanente controlesommen voor archieven nooit gegarandeerd waren. Nadat was aangetoond dat er een enorme hoeveelheid werk nodig zou zijn om de metadata in verschillende ecosystemen bij te werken om de functionaliteit van de getroffen buildsystemen te herstellen, veranderden GitHub-vertegenwoordigers van gedachten, draaiden de wijziging terug en gaven de oude methode voor het genereren van archieven terug.
De Git-ontwikkelaars zijn nog niet tot een besluit gekomen en bespreken alleen mogelijke acties. Tot de overwogen opties behoorden onder meer het terugkeren naar het gebruik van het standaard gzip-hulpprogramma; het toevoegen van de vlag β--stableβ om de compatibiliteit met oude archieven te behouden; het koppelen van de ingebouwde implementatie aan een apart archiefformaat; het gebruik van het gzip-hulpprogramma voor oude commits en de inline-implementatie voor commits die vanaf een bepaalde datum beginnen; het garanderen van formaatstabiliteit alleen voor ongecomprimeerde archieven.
De moeilijkheid bij het nemen van een beslissing wordt verklaard door het feit dat het terugdraaien naar een oproep naar een extern hulpprogramma het probleem van de onveranderlijkheid van de controlesom niet volledig oplost, aangezien een verandering in het externe gzip-programma ook kan leiden tot een verandering in het archiefformaat. Momenteel is er ter beoordeling een reeks patches voorgesteld die standaard het oude gedrag retourneren (een extern gzip-hulpprogramma aanroepen) en de ingebouwde implementatie gebruiken als er geen gzip-hulpprogramma in het systeem aanwezig is. De patches voegen ook aan de documentatie een vermelding toe dat de stabiliteit van de "git archive"-uitvoer niet gegarandeerd is en dat het formaat in de toekomst kan veranderen.
Bron: opennet.ru