Linus Torvalds požiadal správcu kernel.org, aby okamžite zablokoval účet Kesa Cuka, bývalého hlavného systémového administrátora kernel.org a lídra Ubuntu Security Team, ktorý spravuje v jadre 14 podsystemov súvisiacich s bezpečnosťou. Konstantin Ryabtsev, zodpovedný za prácu infraštruktúry kernel.org, zablokoval účet. Dôvodom na zablokovanie bol pull request na zaradenie zmien do vetvy jadra 6.16, odkazujúci na git repozitár, v ktorom bola zmenená informácia o autorstve niektorých commitov.
V podpornom git repozitári spravovanom Kesom sa nachádzali fiktívne zmeny, v poli autora a commitera bol uvedený 'Linus Torvalds', ale Linus ich nepridal. Napríklad pod menom Linusa bola v Kesovej vetve commit, ktorý opakoval iný commit v Linusovej vetve, ale s iným SHA1 hashom. Obe commity vyzerajú rovnako, s výnimkou informácií o podpise.
Zmeny nevykazovali znaky náhodnej chyby pri vykonávaní operácie 'git rebase', pretože obsahovali nesprávne informácie o autorovi commitu. Linus Torvalds to považoval za stopy potenciálne škodlivej aktivity a inicioval zablokovanie prijímania akýchkoľvek zmien od Kesa, kým sa nezistia príčiny týchto manipulácií a nepotvrdí, že Kesov systém nebol kompromitovaný.
Kes odpovedal, že nechápe, ako sa to mohlo stať. Predtým mal problémy pri pokuse o zlúčenie viacerých svojich git vetiev, po čom sa ich snažil vyriešiť operáciou 'git rebase', ale zdá sa, že to nepomohlo. Všetko toto sa dialo na pozadí poruchy SSD disku, ktorý vykazoval chyby počas kopírovania. Kes veril, že po poruche sa mu podarilo obnoviť stav svojich repozitárov, ale zdá sa, že to tak nie je. Na obnovenie integrity sa Kes plánuje znova vytvoriť svoje vetvy z jednotlivých patchov. Ako najpravdepodobnejšiu príčinu vzniknutej zmeny autora Kes považuje neúspešný pokus o obnovenie repozitára po jeho poškodeniu.
Linus nebolo takéto vysvetlenie prijateľné, pretože podľa neho sú zmeny histórie commitov v repozitári Kesa veľmi podobné zámerným činom a nie náhodnej chybe. Prebase histórie zmien operáciou „git rebase“ mohol vysvetliť prepísanie commitera, ale Linus nedokáže pochopiť, ako mohla byť takáto operácia „git rebase“ vykonaná omylom.
Prepísanie jedného alebo dvoch commitov by sa ešte dalo pripísať na chybu, ale v repozitári Kesa bolo prepísaných viac ako šesť tisíc merge commitov, z ktorých v 330 bolo autorom uvedené Linus, pričom tieto commity neboli získané z git stromu Linusa. Vykonané zmeny viac pripomínajú prácu skriptu, ako výsledok poškodenia informácií na úložisku, pretože si vyžadujú osobitné opätovné vytvorenie kópie každého commitu.
Kes uistil Linusa, že to neurobil zámerne a že by sa podobné experimenty bez varovania nezúčastnil (napríklad predchádzajúci experiment so spôsobením kolízií commitov bol dohodnutý s Linusom). Tento týždeň vykonal niekoľko ručných operácií s repozitárom a teraz sa pokúsi zistiť, čo sa pokazilo, a reprodukovať problém. Napríklad Kes vykonával operáciu rebase pre git stromy for-next/hardening a for-linus/hardening, pričom na rozdiel od predchádzajúcich podobných transformácií používal vetvu „master“ namiesto rc2. Počas tejto operácie vykonal zmeny v skriptoch na kontrolu push požiadaviek.
Doplnok: Kes Cook publikoval ďalšiu správu, v ktorej uviedol, že problém pravdepodobne vznikol v dôsledku použitia nástroja „git-filter-repo“, ktorý vykonáva prepísanie histórie commitov v repozitári, v kombinácii s príkazom „b4 trailers“, slúžiacim na získavanie a aplikovanie trailerov na commity (napríklad „Signed-off-by:“).
Zdroj: opennet.ru
