A GitHub megváltoztatta a kiadási oldalak automatikusan generált „.tar.gz” és „.tgz” archívumok létrehozási módját, ami a hash-értékek megváltozását és tömeges összeomlásokat okozott az automatizált build rendszerekben, amelyek a letöltött GitHub archívumok integritásának ellenőrzésére korábban eltárolt hash-értékeket hasonlítanak össze, például a csomagok metaadataiban vagy a build szkriptekben találhatókkal.
A 2.38-as Git verzió megjelenésétől kezdve a Git eszközkészletében alapértelmezetten bekapcsolták a gzip beépített megvalósítását, amely lehetővé tette, hogy egységesítsék ezt a tömörítési módszert a különböző operációs rendszerekben, és növelte az archívumok létrehozásának teljesítményét. A GitHub átvette a változást miután frissítette a git verzióját az infrastruktúrájában. A probléma abból adódott, hogy a zlib alapú beépített gzip megvalósítással generált tömörített archívumok binárisan különböznek a gzip utilitária által létrehozott archívumoktól, ami eltéréseket eredményezett a különböző git verziók által készített archívumok hash-értékeiben a „git archive” parancs végrehajtásakor.
Ennek megfelelően, miután a git frissült a GitHub-on, a kiadási oldalakon kicsit más archívumokat kezdtek el megadni, amelyek nem feleltek meg a régi hash-értékeknek. A probléma különböző build rendszereken, folyamatos integrációs rendszereken és a forráskódokból készült csomagok buildelésére szolgáló eszközökben jelentkezett. Például körülbelül 5800 FreeBSD port buildelése megszakadt, amelyek forráskódját GitHub-ról töltötték le.
Az első összeomlásokra vonatkozó panaszokra válaszul a GitHub képviselői kezdetben arra hivatkoztak, hogy az archívumok hash-értékeinek állandósága soha nem volt garantálva. Miután azonban kiderült, hogy a változás által érintett build rendszerek helyreállítása óriási munkát igényel a metaadatok frissítésében a különböző ökoszisztémákban, a GitHub képviselői megváltoztatták a véleményüket, visszavonták a változást és visszatértek a régi archívum-generálási módszerhez.
A Git fejlesztői még nem jutottak megoldásra, és csak a lehetséges intézkedéseket vitatják. Olyan lehetőségeket mérlegeltek, mint a gzip segédprogram alapértelmezett használatához való visszatérés; a régi archívumokkal való kompatibilitás megőrzésére szolgáló „—stable” kapcsoló hozzáadása; a beépített megvalósítás külön archívumformátumhoz való kötése; a régi commitokhoz a gzip segédprogram használata, és a beépített megvalósítás használata a meghatározott dátumtól kezdődő commitokhoz; a formátum stabilitásának garantálása csak a tömörítetlen archívumok számára.
A döntéshozatal nehézségét az magyarázza, hogy a külső segédprogram hívásának visszaállítása nem oldja meg teljesen a hash ellenőrzős összeg változatlanságának problémáját, mivel a gzip külső programban végzett változtatások szintén a formátum megváltozásához vezethetnek. Jelenleg egy olyan patch-sorozat van felajánlva, amely alapértelmezetten visszaállítja a régi működést (a gzip külső segédprogram hívása), és a beépített megvalósítást használja, ha a rendszerben nincs gzip segédprogram. A patch-ek említést tesznek arról is a dokumentációban, hogy a „git archive” kimenetének stabilitása nem garantált, és a formátum a jövőben megváltozhat.
Forrás: opennet.ru
