A GitHub megváltoztatta az automatikusan generált „.tar.gz” és „.tgz” archívumok létrehozásának módját a kiadási oldalakon, ami változásokhoz vezetett az ellenőrző összegekben, és súlyos hibákhoz vezetett az olyan automatizált összeállítási rendszerekben, amelyek a GitHubról letöltött archívumokat a korábbiakkal összehasonlítva ellenőrzik az integritást. tárolt ellenőrző összegeket, például a csomag metaadataiban vagy az összeállítási szkriptekben elhelyezve.
A 2.38-as kiadástól kezdődően a Git eszközkészlet alapértelmezés szerint tartalmazta a gzip beépített megvalósítását, amely lehetővé tette ennek a tömörítési módszernek az egyesített támogatását az operációs rendszerek között, és javította az archívum létrehozási teljesítményét. A GitHub azután vette át a változást, hogy frissítette a git verzióját az infrastruktúrájában. A problémát az okozta, hogy a beépített zlib alapú gzip implementáció által generált tömörített archívumok binárisan különböznek a gzip segédprogram által létrehozott archívumoktól, ami a git különböző verziói által létrehozott archívumok esetében eltérő ellenőrzőösszegeket eredményezett a program végrehajtása során. "git archive" parancs.
Ennek megfelelően a git GitHubban történő frissítése után kissé eltérő archívumok kezdtek megjelenni a kiadási oldalakon, amelyek nem mentek át a régi ellenőrző összegek ellenőrzésén. A probléma a különféle build rendszerekben, folyamatos integrációs rendszerekben, valamint a forráskódból csomagokat építő eszközökben nyilvánult meg. Például a mintegy 5800 FreeBSD-port összeállítása, amelyek forráskódja a GitHubról lett letöltve, megszakadt.
A hibákkal kapcsolatos kezdeti panaszokra reagálva a GitHub eleinte arra hivatkozott, hogy az archívumok állandó ellenőrző összegét soha nem garantálták. Miután bebizonyosodott, hogy a metaadatok frissítése a különböző ökoszisztémákban hatalmas munkát igényel az érintett buildrendszerek működőképességének helyreállítása, a GitHub képviselői meggondolták magukat, visszaállították a változtatást, és visszaadták az archívumok generálásának régi módszerét.
A Git fejlesztői még nem hoztak döntést, és csak a lehetséges lépésekről tárgyalnak. A mérlegelt opciók között szerepelt az alapértelmezett gzip segédprogram használatára való visszatérés; a „--stable” jelző hozzáadása a régi archívumokkal való kompatibilitás megőrzéséhez; a beépített megvalósítás összekapcsolása külön archív formátumhoz; a gzip segédprogram használata a régi véglegesítésekhez és a soron belüli megvalósítás a bizonyos dátumtól kezdődő véglegesítésekhez; csak a tömörítetlen archívumok formátumstabilitását garantálja.
A döntés nehézségét az magyarázza, hogy egy külső segédprogram hívására való visszagörgetés nem oldja meg teljesen az ellenőrzőösszeg megváltoztathatatlanságának problémáját, hiszen a külső gzip program változása az archívum formátumának megváltozásához is vezethet. Jelenleg felülvizsgálatra javasoltak egy olyan javításkészletet, amely alapértelmezés szerint a régi viselkedést adja vissza (külső gzip segédprogramot hív), és a beépített megvalósítást használja, ha a rendszerben nincs gzip segédprogram. A javítások azt is megemlítik a dokumentációban, hogy a "git archívum" kimenet stabilitása nem garantált, és a formátum a jövőben változhat.
Forrás: opennet.ru