GitHub ka ndryshoi metodën e formimit të arkivave automatikisht të gjeneruar «.tar.gz» dhe «.tgz» në faqet me lëshime, duke çuar në ndryshimin e sums kontrolle dhe dështime masive në sistemet automatike të ndërtimit, të cilat për të konfirmuar integritetin kryejnë verifikimin e arkivave të shkarkuara nga GitHub me sums kontrollesh të ruajtura më parë, për shembull, të vendosura në metadata të pakove ose në skenarë ndërtimi.
Duke filluar nga lëshimi 2.38, në mjetet e Git u përfshi si standard implementimi i brendshëm i gzip, i cili mundësonte unifikimin e mbështetjes së këtij metode kompresimi në sisteme të ndryshme operative dhe rritjen e performancës gjatë krijimit të arkivave. GitHub e mori këtë ndryshim pas përditësimit të versionit git në infrastrukturën e saj. Problemi u shkaktua nga fakti se arkivat e kompresuara, të gjeneruara nga implementimi i brendshëm gzip mbi zlib, duken ndryshe nga arkivat e krijuara nga utilita gzip, çka solli në diferenca në sums kontrollesh për arkivat e krijuara nga versione të ndryshme git gjatë kryerjes së komandës «git archive».
Kështu, pas përditësimit të git në GitHub, në faqet e lëshimeve filluan të ofrohen pak a shumë arkiva të ndryshme, të cilat nuk kalonin verifikimin sipas sums kontrollesh të vjetra. Problemi u shfaq në sisteme të ndryshme ndërtimi, në sistemet e integrimit të vazhdueshëm dhe në mjetet e ndërtimit të pakove nga kodet burimore. Për shembull, ndërtimi i rreth 5800 porteve FreeBSD u prish, për të cilat kodet burimore u shkarkuan nga GitHub.
Në përgjigje të ankesave të para për dështimet e shfaqura, përfaqësuesit e GitHub fillimisht u referuan në faktin se sums kontrolluese për arkivat nuk janë kurrë garantuar. Pas demonstrimit se për riparimin e funksionalitetit të sistemeve të ndërtimit, të cilat u preken nga ndryshimi, do të kërkohej një punë kolosale për përditësimin e metadatan në ekosistemet e ndryshme, përfaqësuesit e GitHub ndryshuan mendim, anuluan ndryshimin dhe riktheu metodën e vjetër të gjenerimit të arkivave.
Zhvilluesit e Git nuk kanĂ« arritur ende nĂ« njĂ« zgjidhje dhe po diskutojnĂ« veprimet e mundshme. U shqyrtuan opsione tĂ« tilla si kthimi nĂ« pĂ«rdorimin e mjetit gzip si tĂ« parazgjedhur; shtimi i flagut "âstable" pĂ«r ruajtjen e kompatibilitetit me arkivat e vjetra; lidhja e realizimit tĂ« integruar me njĂ« format tĂ« veçantĂ« arkivi; pĂ«rdorimi i mjetit gzip pĂ«r komitetet e vjetrĂ« dhe realizimi i integruar pĂ«r komitetet duke filluar nga njĂ« datĂ« e caktuar; garantimi i stabilitetit tĂ« formatit vetĂ«m pĂ«r arkivat qĂ« nuk janĂ« tĂ« kompresuar.
Veshtirësia e marrjes së një vendimi shpjegohet nga fakti se kthimi në thirrjen e një mjeti të jashtëm nuk e zgjidh plotësisht problemin e pandryshueshmërisë së kontrolleve të shumës, pasi një ndryshim në programin e jashtëm gzip gjithashtu mund të çojë në ndryshimin e formatit të arkivit. Aktualisht është propozuar një grup patch-e për rishikim, i cili kthen si të parazgjedhur sjelljen e vjetër (thirrja e mjetit të jashtëm gzip) dhe përdor realizimin e integruar në mungesë të mjetit gzip në sistem. Patch-et gjithashtu shtojnë në dokumentacion përmendjen se stabiliteti i daljes "git archive" nuk garantohet dhe formati mund të ndryshohet në të ardhmen.
Burimi: opennet.ru
