{"id":106631,"date":"2023-02-03T18:48:10","date_gmt":"2023-02-03T16:48:10","guid":{"rendered":"https:\/\/prohoster.info\/?p=106631"},"modified":"2023-02-03T21:50:32","modified_gmt":"2023-02-03T19:50:32","slug":"sboi-v-sistemah-sborki-iz-za-izmeneniya-kontrolnyh-summ-arhivov-v-github","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/sboi-v-sistemah-sborki-iz-za-izmeneniya-kontrolnyh-summ-arhivov-v-github","title":{"rendered":"Fouten in de buildsystemen door wijzigingen in de controle-sommen van archieven op GitHub","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
GitHub heeft de methode voor het genereren van automatisch aangemaakte archieven \u2018.tar.gz\u2019 en \u2018.tgz\u2019 op de releasepagina's veranderd, wat heeft geleid tot wijzigingen in hun controlesommen en massale storingen in geautomatiseerde buildsystemen die ter bevestiging van de integriteit de gedownloade archieven van GitHub vergelijken met eerder opgeslagen controlesommen, bijvoorbeeld die in de metadata van pakketten of in buildscripts. <\/p>\n
Met de release 2.38 is er in de Git-toolkit standaard een ingebouwde implementatie van gzip toegevoegd, die de ondersteuning voor deze compressiemethode in verschillende besturingssystemen heeft verenigd en de prestaties van het archiveren heeft verbeterd. GitHub heeft de verandering opgepikt na de update van de git-versie in zijn infrastructuur. Het probleem werd veroorzaakt doordat de gecomprimeerde archieven, gegenereerd door de ingebouwde gzip-implementatie op basis van zlib, binair verschillen van de archieven die door de gzip-tool zijn aangemaakt, wat leidde tot verschillen in controlesommen voor archieven die door verschillende versies van git zijn aangemaakt bij de uitvoering van het commando \u2018git archive\u2019. <\/p>\n
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. <\/p>\n
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\u00efnvloed, 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. <\/p>\n
De ontwikkelaars van Git hebben nog geen oplossing gevonden en bespreken alleen mogelijke acties. Er zijn verschillende opties overwogen, zoals het terugschakelen naar het gebruik van de gzip-tool als standaard; het toevoegen van de vlag \u2018\u2014stable\u2019 voor het behoud van compatibiliteit met oude archieven; het koppelen van de ingebouwde implementatie aan een apart archiefformaat; het gebruik van de gzip-tool voor oude commits en de ingebouwde implementatie voor commits vanaf een bepaalde datum; en het waarborgen van de stabiliteit van het formaat alleen voor ongecomprimeerde archieven. <\/p>\n
De moeilijkheid om een beslissing te nemen wordt verklaard door het feit dat het terugschakelen naar de oproep van een externe tool het probleem van de onveranderlijkheid van controlesommen niet volledig oplost, omdat wijzigingen in de externe gzip-tool ook kunnen leiden tot veranderingen in het archiefformaat. Op dit moment is er een set patches voorgesteld voor beoordeling, die het oude gedrag (de oproep van de externe gzip-tool) standaard herstelt en de ingebouwde implementatie gebruikt wanneer de gzip-tool niet op het systeem aanwezig is. De patches voegen ook een vermelding in de documentatie toe dat de stabiliteit van de uitvoer van \u2018git archive\u2019 niet gegarandeerd is en dat het formaat in de toekomst kan worden gewijzigd. \n Bron: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"