GitHub het die manier verander waarop die outo-gegenereerde ".tar.gz" en ".tgz" argiewe op die vrystellingbladsye gegenereer word, wat gelei het tot veranderinge in hul kontrolesomme en massiewe mislukkings in outomatiese boustelsels wat die integriteit van argiewe wat afgelaai is, verifieer van GitHub teen voorheen gestoor kontrolesomme, soos diΓ© wat in pakketmetadata of in bouskrifte geplaas is.
Begin met vrystelling 2.38, het die Git-gereedskapstel by verstek 'n ingeboude implementering van gzip ingesluit, wat die verenigende ondersteuning vir hierdie kompressiemetode oor bedryfstelsels moontlik gemaak het en die werkverrigting van die skep van argiewe verbeter het. GitHub het die verandering opgetel nadat hulle die weergawe van git in hul infrastruktuur opgedateer het. Die probleem was dat die saamgeperste argiewe wat deur die ingeboude zlib-gebaseerde gzip-implementering gegenereer word, binΓͺr verskil van die argiewe wat deur die gzip-nutsprogram geskep is, wat gelei het tot verskillende kontrolesomme vir argiewe wat deur verskillende weergawes van git geskep is wanneer die "git-argief" uitgevoer word. bevel.
Gevolglik, na die opdatering van git in GitHub, het effens verskillende argiewe op die vrystellingbladsye begin word wat nie die tjek teen die ou kontrolesomme geslaag het nie. Die probleem het hom gemanifesteer in verskeie boustelsels, deurlopende integrasiestelsels en gereedskapstelle vir die bou van pakkette vanaf bron. Byvoorbeeld, ongeveer 5800 FreeBSD-poorte is gebreek, waarvan die bronne vanaf GitHub afgelaai is.
In reaksie op vroeΓ« klagtes oor ongelukke, het GitHub-verteenwoordigers aanvanklik daarop gewys dat konstante kontrolesomme vir argiewe nooit gewaarborg is nie. Nadat daar gewys is dat om boustelsels wat deur die verandering geraak word, 'n groot hoeveelheid werk sal verg om die metadata in verskeie ekosisteme op te dateer, het GitHub van plan verander, die verandering teruggedraai en die ou metode om argiewe te genereer teruggebring.
Die Git-ontwikkelaars het nog nie tot 'n besluit gekom nie en bespreek slegs moontlike aksies. Opsies wat oorweeg word, sluit in om terug te val na die gebruik van die verstek gzip-nutsding; die toevoeging van die "--stabiele" vlag om verenigbaarheid met ouer argiewe te handhaaf; bind die ingeboude implementering aan 'n aparte argiefformaat; die gebruik van die gzip-nutsding vir ou commits en die ingeboude implementering vir commits wat vanaf 'n sekere datum begin; waarborg formaatstabiliteit slegs vir ongecomprimeerde argiewe.
Die kompleksiteit van die besluit word verklaar deur die feit dat die terugdraai na die oproep van die eksterne hulpprogram nie die probleem van die invariansie van die kontrolesomme heeltemal oplos nie, aangesien 'n verandering in die eksterne gzip-program ook kan lei tot 'n verandering in die argief formaat. Tans word 'n stel pleisters voorgestel vir hersiening, wat by verstek die ou gedrag terugstuur (wat 'n eksterne gzip-nutsprogram noem) en die ingeboude implementering gebruik wanneer die gzip-hulpmiddel nie op die stelsel teenwoordig is nie. Die pleisters voeg ook 'n nota by die dokumentasie dat die uitvoer van "git archive" nie gewaarborg is om stabiel te wees nie en die formaat is onderhewig aan verandering in die toekoms.
Bron: opennet.ru