Linuxi tuuma haru kommitide asendamise intsident Kes Cookilt.

Linus Torvalds nõudis kernel.org administraatorilt, et Kesa Kuuka, endise kernel.org peaasjade administraatori ja Ubuntu turvameeskonna juhi konto tuleks viivitamatult blokeerida, kes haldab 14 turvalisuse alamsüsteemi tuumas. Konstantin Rjabe tsov, kes vastutab kernel.org infrastruktuuri eest, tegi blokeerimise. Blokeerimise põhjuseks oli pull-request tuuma 6.16 harusse, mis viitas git-repositooriumile, kus oli muudetud teavet mõnede kommite autorluse kohta.

Kesa poolt toetatud git-repositooriumis olid olemas valeandmed, kus autori ja kommiteerija väljad olid märgitud 'Linus Torvalds', kuid Linus ei olnud neid lisanud. Näiteks Kesa haru all oli Linuse nime all kommite, mis kordas teist kommite Linuse harust, kuid teise SHA1 hashiga. Mõlemad kommited näevad välja samad, välja arvatud allkirja teave.

Muutused ei näidanud välja juhusliku vea tagajärjel 'git rebase' operatsiooni käigus, kuna need sisaldasid vale teavet kommite autori kohta. Linus Torvalds pidas seda võimaliku kahjuliku tegevuse jälgedeks ja algatas Kesa kõige muudatuste vastuvõtmise blokeerimise, kuni selgitatakse selliste manipulatsioonide põhjuseid ja kinnitatakse, et Kesa süsteem ei ole compromiteeritud.

Kes vastas, et ei mõista, kuidas midagi sellist sai juhtuda. Enne seda oli ta silmitsi probleemidega, püüdes ühendada mitmeid oma git-harusid, pärast mida üritas ta neid probleemide lahendamiseks 'git rebase' operatsiooniga, kuid ilmselt ei aidanud see. Kõik see toimus SSD-draivi rikke taustal, mis andis vigu kopeerimise ajal. Kes arvas, et pärast riket õnnestus tal oma repositooriumide seisund taastada, kuid tundub, et see ei olnud nii. Integriteedi taastamiseks kavatseb Kes oma harud eraldi patchidest uuesti luua. Kõige tõenäolisemaks autori valeandmete põhjuseks peab Kes ebaõnnestunud katset taastada repositoorium pärast selle kahjustamist.

Linus ei olnud sellise seletusega rahul, sest tema arvates on Kesa hoidlas toimuva commitide ajaloo muutmine väga sarnane teadlikule tegevusele, mitte juhuslikule tõrketele. Commitite ümberpõhjustamine 'git rebase' operatsiooniga oleks võinud seletada commit'i kirjutamist uuesti, kuid Linus ei saa aru, kuidas midagi sellist võis kogemata juhtuda.

Ühe või kahe commit'i ümberkirjutamist oleks võinud arvestada eksitusena, kuid Kesa hoidlas oli ülekirjutatud rohkem kui kuus tuhat merge-commit'i, millest 330 puhul oli autoriks Linus, samas kui need commit'id ei olnud saadud Linuse git-puudest. Tehtud muudatused meenutavad pigem skripti tööd kui andmete kahjustamist salvestis, kuna need nõuavad iga commit'i eraldi koopia loomist.

Kes kinnitas Linusele, et ta ei teinud seda tahtlikult ja ei teeks selliseid katseid ilma ette teatamata (näiteks eelmine commit'ide kollisionide tekitamise katse oli Linus'ega kokku lepitud). Sel nädalal tegi ta mõned käsitsi toimingud hoidlas ja nüüd püüab ta välja selgitada, mis valesti läks, ja probleem tekitada. Näiteks tegi Kes rebase'i for-next/hardening ja for-linus/hardening git-puudega, kasutades erinevalt varasemast tõlkest haru 'master', mitte rc2. Selle operatsiooni käigus tegi ta muudatusi skriptides, et kontrollida push-päringute olemasolu.

Täiendav teade: Kes Cook avaldas veel ühe postituse, kus ta teatas, et probleem tekkis tõenäoliselt 'git-filter-repo' utiliidi kasutamisest, mis kirjutab commit'ide ajaloo ümber, koos käsklusega 'b4 trailers', mis on mõeldud trailerite saamiseks ja rakendamiseks commit'idele (näiteks 'Signed-off-by:').

Allikas: opennet.ru