Kvarovi u sustavima izrade zbog promjena u kontrolnim zbrojevima arhive na GitHubu

GitHub je promijenio način na koji generira automatski generirane arhive ".tar.gz" i ".tgz" na stranicama izdanja, što je dovelo do promjena u njihovim kontrolnim zbrojevima i masovnih kvarova u automatiziranim sustavima izrade koji provjeravaju arhive preuzete s GitHuba u odnosu na prethodne kako bi potvrdili integritet pohranjene kontrolne zbrojeve, na primjer, smještene u metapodatke paketa ili u skripte za izgradnju.

Počevši od izdanja 2.38, Git toolkit uključuje ugrađenu implementaciju gzip-a prema zadanim postavkama, što je omogućilo objedinjavanje podrške za ovu metodu kompresije u svim operativnim sustavima i poboljšanje performansi stvaranja arhive. GitHub je pokupio promjenu nakon ažuriranja verzije gita u svojoj infrastrukturi. Problem je uzrokovan činjenicom da su komprimirane arhive koje je generirala ugrađena gzip implementacija temeljena na zlibu binarno različite od arhiva koje je stvorio gzip uslužni program, što je rezultiralo različitim kontrolnim zbrojevima za arhive koje su stvorile različite verzije git-a prilikom izvođenja naredba "git arhiva".

Sukladno tome, nakon ažuriranja gita u GitHubu, na stranicama izdanja počele su se prikazivati ​​malo drugačije arhive koje nisu prošle provjeru pomoću starih kontrolnih zbrojeva. Problem se očitovao u različitim sustavima za izgradnju, sustavima za kontinuiranu integraciju i alatima za izgradnju paketa iz izvornog koda. Na primjer, pokvaren je sklop od oko 5800 FreeBSD portova, čiji su izvorni kodovi preuzeti s GitHuba.

Kao odgovor na početne pritužbe o greškama, GitHub je isprva naveo činjenicu da trajni kontrolni zbrojevi za arhive nikada nisu zajamčeni. Nakon što se pokazalo da će biti potrebna ogromna količina posla za ažuriranje metapodataka u različitim ekosustavima kako bi se vratila funkcionalnost zahvaćenih sustava izgradnje, predstavnici GitHuba su se predomislili, poništili promjenu i vratili staru metodu generiranja arhiva.

Programeri Gita još nisu donijeli odluku i samo razgovaraju o mogućim akcijama. Razmatrane opcije uključivale su vraćanje na korištenje zadanog uslužnog programa gzip; dodavanje oznake “--stable” za održavanje kompatibilnosti sa starim arhivama; povezivanje ugrađene implementacije s zasebnim formatom arhive; korištenje uslužnog programa gzip za stare obveze i ugrađene implementacije za obveze koje počinju od određenog datuma; jamčeći stabilnost formata samo za nekomprimirane arhive.

Teškoća donošenja odluke objašnjava se činjenicom da vraćanje na poziv vanjskom uslužnom programu ne rješava u potpunosti problem nepromjenjivosti kontrolnog zbroja, budući da promjena u vanjskom gzip programu također može dovesti do promjene formata arhive. Trenutačno je za pregled predložen skup zakrpa koji prema zadanim postavkama vraća staro ponašanje (pozivanje vanjskog uslužnog programa gzip) i koristi ugrađenu implementaciju u nedostatku uslužnog programa gzip u sustavu. Zakrpe također dodaju u dokumentaciju spominjanje da stabilnost izlaza "git archive" nije zajamčena i da se format može promijeniti u budućnosti.

Izvor: opennet.ru

Dodajte komentar