Ilang araw na ang nakakalipas isang hindi pangkaraniwang pangyayari ang naganap, na yumanig sa Linux kernel community, at iyon nga Iniutos ni Linus Torvalds ang agarang pagsususpinde ng account ni Kees Cook sa kernel.org., pagkatapos matukoy ang pagkakaroon ng manipulated commits sa Git repository ng developer na ito.
Kees Cook, kinikilala sa kanyang pamumuno sa pangkat ng seguridad ng Ubuntu at para sa pagpapanatili ng higit sa isang dosenang mga subsystem na nauugnay sa seguridad ng kernel, ay pansamantalang ipinagbawal sa pagsusumite ng mga pagbabago habang nilinaw ang mga katotohanan.
Pagbabago ng pagiging may-akda at mga lagda sa repositoryo ng Kees Cook
Ang problema ay lumitaw mula sa isang kahilingan sa pagsasama ng pagbabago.s sa 6.16 kernel branch, kung saan tinukoy ni Linus ang mga sanggunian sa isang repositoryo naglalaman iyon commit manipulahin sa ang kanyang pangalan bilang may-akda at nagpapatunay, sa kabila ng hindi niya ginawa mismo. Isa sa mga pinakaseryosong halimbawa ay ang pagkakaroon ng duplicate na commit, kapareho ng nilalaman sa orihinal ngunit may ibang SHA1 hash, na maling kasama ang lagda ni Linus Torvalds.
Ang mga pagbabagong ito hindi maaaring maiugnay lamang sa isang hindi sinasadyang pagkakamalil sa panahon ng git rebase operation, dahil kasangkot sila ng napakalaking pagbabago ng sensitibong impormasyon, kabilang ang higit sa 6.000 muling isinulat na mga pangako, 330 sa mga ito ay may pangalan ni Linus bilang may-akda.
Reaksyon ni Torvalds: mga hinala ng sadyang pagmamanipula
Hindi itinago ni Linus Torvalds ang kanyang pag-aalala at inilarawan ang mga kaganapan bilang potensyal na nakakapinsala:
"Ang isa o dalawang rewrite ay maaaring isang pagkakamali. Ngunit libu-libo sa kanila, marami sa aking pekeng lagda, ay hindi," deklara niya.
Dahil sa laki ng mga pagbabago at panganib sa integridad ng opisyal na kernel tree, Tinanong ni Torvalds si Konstantin Ryabitsev, administrator ng imprastraktura ng kernel.org, qupang harangan ang pag-access ni Kees Cook hanggang sa linawin ang sitwasyon.
Bilang tugon, Ipinaliwanag ni Kees Cook na nagkaroon siya ng mga problemang teknikal kamakailan na maaaring mag-trigger ng insidente. sabi niya, Ang iyong SSD drive ay nakakaranas ng mga error sa panahon ng mga operasyon ng pagkopya, na nagdulot ng katiwalian sa ilang mga repositoryo. Pagkatapos ng mga error na ito, sinubukan niyang bawiin ang estado ng kanyang repository gamit ang git rebase at iba't ibang mga tool sa automation.
Gayunpaman, ang mga operasyong ito ay isinagawa sa mga kritikal na sangay, gaya ng for-next/hardening at for-linus/hardening, na humantong sa hindi sinasadyang pagbabago ng kasaysayan ng repositoryo, kabilang ang pagbabago sa pagiging may-akda ng mga commit. Sa kabila ng kanyang paliwanag, nag-aalinlangan si Linus.:
"Hindi ko maintindihan kung paano maaaring mangyari ang isang hindi sinasadyang pag-overtake, lalo na sa dami ng mga pagbabago."
Ang tunay na salarin: git-filter-repo at b4 trailer
Sa susunod na mensahe, Natukoy ni Kees Cook ang posibleng pinagmulan ng error: ang pinagsamang paggamit ng dalawang kasangkapan, git-filter-repo at b4 trailer, na nagmamanipula sa kasaysayan ng commit at mga trailer (mga tag tulad ng Signed-off-by:) sa mga commit.
Ang maling paggamit na ito ng mga kita magiging sanhi ng awtomatikong muling pagsusulat ng libu-libong commit, kabilang ang pagpapalit sa may-akda ng default na halaga (sa kasong ito, Linus Torvalds), nang hindi napapansin ni Kees ang error sa oras na iyonKinumpirma ni Konstantin Ryabitsev, may-akda ng tool na b4, ang teoryang ito at iginiit na walang masamang hangarin sa bahagi ni Cook. Sa katunayan, ang sistema ay gumagawa na ng mga babala na hindi pinansin.
Matapos linawin ang sitwasyon, naibalik ang access ni Kees Cook sa kernel.org. Bilang isang preventive measure, inihayag na ang tool b4 ay magsasama ng isang bagong tseke ng seguridad, Pipigilan nito ang pagbabago ng mga commit na ang pagiging may-akda ay hindi tumutugma sa pagkakakilanlan ng kasalukuyang user mula ngayon. Ito ay nilayon upang maiwasan ang mga katulad na error at protektahan ang integridad ng kernel source code.
Si Kees, sa kanyang bahagi, ay nangako na muling likhain ang mga apektadong sangay. mula sa mga indibidwal na patch at suriin nang malalim ang mga hakbang na humantong sa error. Bagaman Ang insidente ay nagdulot ng hindi magandang relasyon sa loob ng koponan kernel development, ay binigyang-diin din ang kahalagahan ng paggamit ng history rewriting tools nang may pag-iingat, lalo na sa mga proyektong kasing kritikal ng Linux kernel.
Sa wakas, nararapat na banggitin na ang insidenteng ito sa pagitan nina Linus Torvalds at Kees Cook ay nagsisilbing babala tungkol sa mga panganib ng pagmamanipula ng commit history at na salamat sa mabilis na interbensyon mula sa mga responsable para sa kernel.org at ang transparency ng proseso, nakontrol na ang sitwasyon.
Sa wakas, kung interesado kang matuto nang higit pa tungkol dito, maaari mong suriin ang mga detalye sa sumusunod link