GitHub a schimbat modul în care generează arhivele „.tar.gz” și „.tgz” generate automat pe paginile de lansare, ceea ce a dus la modificări ale sumelor de verificare și eșecuri masive în sistemele automate de construire care verifică arhivele descărcate de pe GitHub față de cele anterioare pentru a confirma integritatea. .sume de control stocate, de exemplu, plasate în metadatele pachetului sau în scripturile de compilare.
Începând cu versiunea 2.38, setul de instrumente Git a inclus o implementare încorporată a gzip în mod implicit, ceea ce a făcut posibilă unificarea suportului pentru această metodă de compresie între sistemele de operare și îmbunătățirea performanței creării arhivelor. GitHub a preluat schimbarea după actualizarea versiunii de git în infrastructura sa. Problema a fost cauzată de faptul că arhivele comprimate generate de implementarea gzip încorporată bazată pe zlib sunt binare diferite de arhivele create de utilitarul gzip, ceea ce a dus la sume de control diferite pentru arhivele create de diferite versiuni de git la executarea programului. comanda „git archive”.
În consecință, după actualizarea git în GitHub, arhivele ușor diferite au început să fie afișate pe paginile de lansare, care nu au trecut verificarea folosind vechile sume de control. Problema s-a manifestat în diverse sisteme de construcție, sisteme de integrare continuă și instrumente pentru construirea de pachete din codul sursă. De exemplu, ansamblul a aproximativ 5800 de porturi FreeBSD, codurile sursă pentru care au fost descărcate de pe GitHub, a fost spart.
Ca răspuns la plângerile inițiale cu privire la erori, GitHub a menționat inițial faptul că sumele de verificare permanente pentru arhive nu au fost niciodată garantate. După ce s-a demonstrat că ar fi necesară o cantitate imensă de muncă pentru a actualiza metadatele din diverse ecosisteme pentru a restabili funcționalitatea sistemelor de construcție afectate, reprezentanții GitHub s-au răzgândit, au revenit la schimbare și au returnat vechea metodă de generare a arhivelor.
Dezvoltatorii Git nu au luat încă o decizie și discută doar posibile acțiuni. Opțiunile luate în considerare au inclus revenirea la utilizarea utilitarului gzip implicit; adăugarea steagului „--stable” pentru a menține compatibilitatea cu arhivele vechi; conectarea implementării încorporate la un format de arhivă separat; utilizarea utilitarului gzip pentru comiterile vechi și implementarea inline pentru comiterile care încep de la o anumită dată; garantând stabilitatea formatului numai pentru arhivele necomprimate.
Dificultatea de a lua o decizie se explică prin faptul că revenirea la un apel către un utilitar extern nu rezolvă complet problema imuabilității sumei de control, deoarece o modificare a programului extern gzip poate duce și la o modificare a formatului de arhivă. În prezent, a fost propus pentru revizuire un set de patch-uri care returnează vechiul comportament implicit (apelând un utilitar extern gzip) și utilizează implementarea încorporată în absența unui utilitar gzip în sistem. Patch-urile adaugă documentației și o mențiune că stabilitatea ieșirii „git archive” nu este garantată și formatul se poate schimba în viitor.
Sursa: opennet.ru