GitHub a modificat metoda de generare a arhivelor automatice „.tar.gz” și „.tgz” pe paginile cu lansări, ceea ce a dus la schimbarea sumelor de control și la eșecuri masive în sistemele automatizate de construire care validează integritatea prin verificarea arhivelor descărcate de pe GitHub cu sumele de control salvate anterior, de exemplu, stocate în metadatele pachetelor sau în scripturile de construire.
Începând cu versiunea 2.38, în instrumentele Git a fost inclusă implicit o implementare integrată gzip, care a permis unificarea suportului pentru această metodă de comprimare în diferite sisteme de operare și a sporit performanța creării arhivelor. GitHub a preluat modificarea după actualizarea versiunii git în infrastructura sa. Problema a fost că arhivele comprimate generate de implementarea integrată gzip pe baza zlib sunt diferit binar față de arhivele create de utilitarul gzip, ceea ce a dus la diferențe în sumele de control pentru arhivele generate de versiuni diferite de git atunci când se execută comanda „git archive”.
Astfel, după actualizarea git în GitHub, pe paginile lansărilor au fost livrate arhive puțin diferite, neacceptate de vechile sume de control. Problema s-a manifestat în diferite sisteme de construire, în sistemele de integrare continuă și în instrumentele de construire a pachetelor din surse. De exemplu, construcția a aproximativ 5800 de porturi FreeBSD a fost afectată, iar codurile sursă pentru acestea au fost descărcate de pe GitHub.
În răspuns la primele plângeri referitoare la eșecurile apărute, reprezentanții GitHub au declarat inițial că sumele de control constante pentru arhive nu au fost niciodată garantate. După ce s-a demonstrat că pentru restabilirea funcționării sistemelor de construire afectate de modificare este necesară o muncă colosală de actualizare a metadatelor în diferite ecosisteme, reprezentanții GitHub și-au schimbat opinia, anulând modificarea și readucând vechea metodă de generare a arhivelor.
Dezvoltatorii Git încă nu au ajuns la o soluție și discută posibile acțiuni. Au fost considerate opțiuni precum revenirea la utilizarea utilitarului gzip implicit; adăugarea unei opțiuni „—stable” pentru a menține compatibilitatea cu arhivele mai vechi; legarea implementării încorporate la un format de arhivă specific; utilizarea utilitarului gzip pentru comit-uri vechi și a implementării încorporate pentru comit-uri începând cu o dată specifică; garantarea stabilității formatului doar pentru arhive necompresate.
Dificultatea luării unei decizii se explică prin faptul că revenirea la apelul unei aplicații externe nu rezolvă complet problema invariabilității hash-urilor, deoarece modificarea în programul extern gzip poate, de asemenea, să conducă la modificarea formatului arhivei. În prezent, pentru revizuire a fost propus un set de patch-uri care restituie comportamentul vechi implicit (apelul aplicației externe gzip) și folosește implementarea încorporată în absența aplicației gzip în sistem. Patch-urile adaugă, de asemenea, în documentație mențiunea că stabilitatea ieșirii „git archive” nu este garantată și formatul poate fi modificat în viitor.
Sursa: opennet.ro
