GitHub heeft de manier waarop automatisch gegenereerde archieven in «.tar.gz» en «.tgz» worden gemaakt op de relepagina's veranderd, wat leidde tot veranderingen in hun controlesommen en massale storingen in geautomatiseerde buildsystemen die de integriteit verifiëren door de gedownloade archieven van GitHub te vergelijken met eerder opgeslagen controlesommen, bijvoorbeeld opgenomen in de metadata van pakketten of in buildscripts.
Vanaf versie 2.38 is in de Git-toolkit standaard een ingebouwde gzip-implementatie opgenomen, die het mogelijk maakte om de ondersteuning voor deze compressiemethode te uniformeren op verschillende besturingssystemen en de prestaties van het maken van archieven te verbeteren. GitHub heeft de wijziging overgenomen na de update van de git-versie in zijn infrastructuur. Het probleem werd veroorzaakt doordat de gecomprimeerde archieven die door de ingebouwde gzip-implementatie op basis van zlib worden gegenereerd, binair verschillen van de archieven die door de gzip-tool zijn gemaakt, wat leidde tot verschillen in controlesommen voor archieven die door verschillende versies van git zijn gemaakt bij het uitvoeren van de «git archive»-opdracht.
Als gevolg hiervan begonnen de pagina's met releases op GitHub na de update van git andere archieven te retourneren die niet door de oude controlesommen gingen. Het probleem manifesteerde zich in verschillende buildsystemen, continue integratiesystemen en in tools voor het bouwen van pakketten uit de broncode. Bijvoorbeeld, de build van ongeveer 5800 FreeBSD-poorten waar de broncode van GitHub werd gedownload, werd verstoord.
In reactie op de eerste klachten over de opgetreden storingen verwezen vertegenwoordigers van GitHub aanvankelijk naar het feit dat vaste controlesommen voor archieven nooit gegarandeerd werden. Nadat was aangetoond dat het herstel van de functionaliteit van de buildsystemen die door de wijziging werden beïnvloed, een enorme inspanning zou vergen voor het bijwerken van metadata in verschillende ecosystemen, veranderden de vertegenwoordigers van GitHub van mening, trok de wijziging terug en herstelde de oude methode voor het genereren van archieven.
Git-ontwikkelaars hebben nog geen oplossing gevonden en bespreken alleen mogelijke acties. Er werden opties overwogen zoals terugkeer naar het standaard gebruik van de gzip-tool; toevoeging van de vlag "—stable" voor het behoud van compatibiliteit met oude archieven; koppeling van de ingebouwde implementatie aan een afzonderlijk archiefformaat; gebruik van de gzip-tool voor oude commits en de ingebouwde implementatie voor commits vanaf een bepaalde datum; en het garanderen van de stabiliteit van het formaat alleen voor ongecomprimeerde archieven.
De moeilijkheid bij het nemen van een beslissing wordt verklaard door het feit dat de terugkeer naar het aanroepen van een externe tool het probleem van ongewijzigde checksum niet volledig oplost, aangezien een wijziging in het externe programma gzip ook kan leiden tot een wijziging in het archiefformaat. Momenteel wordt er een set patches voorgesteld voor herziening, die het oude gedrag (het aanroepen van de externe gzip-tool) als standaard terugbrengt en de ingebouwde implementatie gebruikt wanneer de gzip-tool niet op het systeem aanwezig is. De patches voegen ook een vermelding aan de documentatie toe dat de stabiliteit van de uitvoer van "git archive" niet gegarandeerd is en dat het formaat in de toekomst gewijzigd kan worden.
Bron: opennet.ru
