ຄວາມລົ້ມເຫລວໃນການກໍ່ສ້າງລະບົບເນື່ອງຈາກການປ່ຽນແປງໃນຄັງເກັບມ້ຽນໃນ GitHub

GitHub ໄດ້ປ່ຽນວິທີທີ່ມັນສ້າງແຟ້ມຈັດເກັບທີ່ສ້າງໂດຍອັດຕະໂນມັດ ".tar.gz" ແລະ ".tgz" ໃນຫນ້າປ່ອຍ, ເຊິ່ງນໍາໄປສູ່ການປ່ຽນແປງໃນ checksums ຂອງພວກເຂົາແລະຄວາມລົ້ມເຫລວຢ່າງໃຫຍ່ຫຼວງໃນລະບົບການກໍ່ສ້າງອັດຕະໂນມັດທີ່ກວດເບິ່ງແຟ້ມທີ່ດາວໂຫລດມາຈາກ GitHub ຕໍ່ກັບອັນກ່ອນຫນ້າເພື່ອຢືນຢັນຄວາມຊື່ສັດ. ຕົວຢ່າງ checksums ທີ່ເກັບໄວ້ໃນແພັກເກັດ metadata ຫຼືໃນ build scripts.

ເລີ່ມຕົ້ນດ້ວຍການປ່ອຍ 2.38, Git toolkit ໄດ້ລວມເອົາການຕິດຕັ້ງ gzip ໂດຍຄ່າເລີ່ມຕົ້ນ, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປະສົມປະສານການສະຫນັບສະຫນູນວິທີການບີບອັດນີ້ໃນທົ່ວລະບົບປະຕິບັດການແລະປັບປຸງປະສິດທິພາບການສ້າງແຟ້ມ. GitHub ໄດ້ຮັບເອົາການປ່ຽນແປງຫຼັງຈາກການປັບປຸງສະບັບຂອງ git ໃນໂຄງສ້າງພື້ນຖານຂອງມັນ. ບັນຫາແມ່ນເກີດມາຈາກຄວາມຈິງທີ່ວ່າຮວບຮວມທີ່ຖືກບີບອັດທີ່ສ້າງຂຶ້ນໂດຍການປະຕິບັດ gzip ທີ່ມີການກໍ່ສ້າງໃນ gzip ແມ່ນ binary ແຕກຕ່າງຈາກ archives ທີ່ສ້າງຂື້ນໂດຍ gzip utility, ເຊິ່ງສົ່ງຜົນໃຫ້ checksums ທີ່ແຕກຕ່າງກັນສໍາລັບ archives ທີ່ສ້າງຂຶ້ນໂດຍ git ຮຸ່ນທີ່ແຕກຕ່າງກັນໃນເວລາດໍາເນີນການ. ຄໍາສັ່ງ "git archive".

ດັ່ງນັ້ນ, ຫຼັງຈາກການປັບປຸງ git ໃນ GitHub, ການເກັບມ້ຽນທີ່ແຕກຕ່າງກັນເລັກນ້ອຍເລີ່ມສະແດງຢູ່ໃນຫນ້າປ່ອຍ, ເຊິ່ງບໍ່ໄດ້ຜ່ານການກວດສອບໂດຍໃຊ້ checksums ເກົ່າ. ບັນຫາໄດ້ສະແດງອອກໃນລະບົບການກໍ່ສ້າງຕ່າງໆ, ລະບົບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ, ແລະເຄື່ອງມືສໍາລັບການກໍ່ສ້າງຊຸດຈາກລະຫັດແຫຼ່ງ. ຕົວຢ່າງ, ການປະກອບຂອງພອດ FreeBSD ປະມານ 5800, ລະຫັດແຫຼ່ງທີ່ດາວໂຫລດຈາກ GitHub, ຖືກທໍາລາຍ.

ໃນການຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງທຸກເບື້ອງຕົ້ນກ່ຽວກັບຄວາມຜິດປົກກະຕິ, GitHub ໃນເບື້ອງຕົ້ນໄດ້ອ້າງເຖິງຄວາມຈິງທີ່ວ່າ checksums ຖາວອນສໍາລັບການເກັບຮັກສາບໍ່ເຄີຍຮັບປະກັນ. ຫຼັງຈາກທີ່ໄດ້ສະແດງໃຫ້ເຫັນວ່າຈໍານວນການເຮັດວຽກຈໍານວນຫຼວງຫຼາຍຈະຕ້ອງໄດ້ປັບປຸງ metadata ໃນລະບົບນິເວດຕ່າງໆເພື່ອຟື້ນຟູການເຮັດວຽກຂອງລະບົບການກໍ່ສ້າງທີ່ໄດ້ຮັບຜົນກະທົບ, ຜູ້ຕາງຫນ້າ GitHub ໄດ້ປ່ຽນໃຈ, ປ່ຽນຄືນການປ່ຽນແປງແລະກັບຄືນວິທີການເກົ່າຂອງການສ້າງແຟ້ມ.

ນັກພັດທະນາ Git ຍັງບໍ່ທັນມີການຕັດສິນໃຈແລະພຽງແຕ່ປຶກສາຫາລືກ່ຽວກັບການປະຕິບັດທີ່ເປັນໄປໄດ້. ທາງເລືອກທີ່ພິຈາລະນາລວມມີການກັບຄືນໄປໃຊ້ gzip utility ເລີ່ມຕົ້ນ; ເພີ່ມທຸງ “-- ໝັ້ນຄົງ” ເພື່ອຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບບ່ອນເກັບມ້ຽນເກົ່າ; ການ​ເຊື່ອມ​ຕໍ່​ການ​ປະ​ຕິ​ບັດ​ການ​ກໍ່​ສ້າງ​ໃນ​ຮູບ​ແບບ​ການ​ເກັບ​ຮັກ​ສາ​ແຍກ​ຕ່າງ​ຫາກ​; ການນໍາໃຊ້ປະໂຫຍດ gzip ສໍາລັບຄໍາຫມັ້ນສັນຍາເກົ່າແລະການຈັດຕັ້ງປະຕິບັດ inline ສໍາລັບຄໍາຫມັ້ນສັນຍາເລີ່ມຕົ້ນຈາກວັນທີທີ່ແນ່ນອນ; ຮັບປະກັນຄວາມຫມັ້ນຄົງຂອງຮູບແບບພຽງແຕ່ສໍາລັບການເກັບ uncompressed.

ຄວາມຫຍຸ້ງຍາກໃນການຕັດສິນໃຈແມ່ນໄດ້ຖືກອະທິບາຍໂດຍຄວາມຈິງທີ່ວ່າ rolling ກັບການໂທໄປຫາຜົນປະໂຫຍດພາຍນອກບໍ່ໄດ້ແກ້ໄຂບັນຫາຂອງ checksum immutability, ເນື່ອງຈາກວ່າການປ່ຽນແປງໃນໂຄງການ gzip ພາຍນອກຍັງສາມາດນໍາໄປສູ່ການປ່ຽນແປງໃນຮູບແບບການເກັບ. ໃນປັດຈຸບັນ, ຊຸດຂອງ patches ໄດ້ຖືກສະເຫນີສໍາລັບການທົບທວນຄືນທີ່ສົ່ງຄືນພຶດຕິກໍາເກົ່າໂດຍຄ່າເລີ່ມຕົ້ນ (ໂທຫາ gzip utility ພາຍນອກ) ແລະນໍາໃຊ້ການຈັດຕັ້ງປະຕິບັດໃນຕົວໃນເວລາທີ່ບໍ່ມີ gzip utility ໃນລະບົບ. ເພີ້ມຕື່ມໃສ່ເອກະສານທີ່ກ່າວເຖິງວ່າຄວາມຫມັ້ນຄົງຂອງຜົນຜະລິດ "git archive" ບໍ່ໄດ້ຮັບການຮັບປະກັນແລະຮູບແບບອາດຈະມີການປ່ຽນແປງໃນອະນາຄົດ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru