Binago ng GitHub ang paraan ng pagbuo nito ng awtomatikong nabuong ".tar.gz" at ".tgz" na mga archive sa mga page ng release, na humantong sa mga pagbabago sa kanilang mga checksum at napakalaking pagkabigo sa mga automated na build system na sinusuri ang mga archive na na-download mula sa GitHub laban sa mga nauna para kumpirmahin ang integridad . mga nakaimbak na checksum, halimbawa, inilagay sa metadata ng package o sa mga build script.
Simula sa release 2.38, ang Git toolkit ay may kasamang built-in na pagpapatupad ng gzip bilang default, na naging posible upang mapag-isa ang suporta para sa paraan ng compression na ito sa mga operating system at pagbutihin ang pagganap ng paggawa ng archive. Kinuha ng GitHub ang pagbabago pagkatapos i-update ang bersyon ng git sa imprastraktura nito. Ang problema ay sanhi ng katotohanan na ang mga naka-compress na archive na nabuo ng built-in na zlib-based na gzip na pagpapatupad ay binary na iba sa mga archive na nilikha ng gzip utility, na nagresulta sa iba't ibang mga checksum para sa mga archive na nilikha ng iba't ibang mga bersyon ng git kapag isinasagawa ang "git archive" na utos.
Alinsunod dito, pagkatapos i-update ang git sa GitHub, nagsimulang ipakita ang bahagyang magkakaibang mga archive sa mga pahina ng paglabas, na hindi pumasa sa pag-verify gamit ang mga lumang checksum. Ang problema ay nagpakita mismo sa iba't ibang build system, tuluy-tuloy na integration system, at mga tool para sa pagbuo ng mga package mula sa source code. Halimbawa, ang pagpupulong ng humigit-kumulang 5800 FreeBSD port, ang mga source code na na-download mula sa GitHub, ay nagambala.
Bilang tugon sa mga paunang reklamo tungkol sa mga aberya, unang binanggit ng GitHub ang katotohanan na ang mga permanenteng checksum para sa mga archive ay hindi kailanman ginagarantiyahan. Matapos maipakita na ang malaking halaga ng trabaho ay kinakailangan upang i-update ang metadata sa iba't ibang ecosystem upang maibalik ang functionality ng mga apektadong build system, binago ng mga kinatawan ng GitHub ang kanilang isip, ibinalik ang pagbabago at ibinalik ang lumang paraan ng pagbuo ng mga archive.
Ang mga developer ng Git ay hindi pa nakakapagdesisyon at tinatalakay lamang ang mga posibleng aksyon. Kasama sa mga opsyong isinasaalang-alang ang pagbabalik sa paggamit ng default na gzip utility; pagdaragdag ng flag na "--stable" upang mapanatili ang pagiging tugma sa mga lumang archive; pag-uugnay ng built-in na pagpapatupad sa isang hiwalay na format ng archive; gamit ang gzip utility para sa mga lumang commit at ang inline na pagpapatupad para sa mga commit simula sa isang tiyak na petsa; ginagarantiyahan ang katatagan ng format para lamang sa mga hindi naka-compress na archive.
Ang kahirapan sa paggawa ng desisyon ay ipinaliwanag sa pamamagitan ng katotohanan na ang pagbabalik sa isang tawag sa isang panlabas na utility ay hindi ganap na malulutas ang problema ng checksum immutability, dahil ang isang pagbabago sa panlabas na programa ng gzip ay maaari ring humantong sa isang pagbabago sa format ng archive. Sa kasalukuyan, ang isang hanay ng mga patch ay iminungkahi para sa pagsusuri na nagbabalik ng lumang gawi bilang default (pagtawag ng panlabas na gzip utility) at gumagamit ng built-in na pagpapatupad sa kawalan ng gzip utility sa system. Ang mga patch ay nagdaragdag din sa dokumentasyon ng pagbanggit na ang katatagan ng "git archive" na output ay hindi ginagarantiyahan at ang format ay maaaring magbago sa hinaharap.
Pinagmulan: opennet.ru