Linus Torvalds a cerut administratorului kernel.org să blocheze imediat contul lui Kesa Cook, fostul administrator principal de sistem al kernel.org și lider al echipei de securitate Ubuntu, care gestionează 14 subsisteme legate de securitate în nucleu. Konstantin Ryabtsev, responsabil cu infrastructura kernel.org, a efectuat blocarea. Motivul pentru blocare a fost un pull request pentru includerea în ramura nucleului 6.16 a unor modificări care făceau referire la un repository git în care au fost modificate informațiile despre autorii unor commit-uri.
În repository-ul git susținut de Kes au fost prezente modificări fictive, în care câmpul autorului și al commit-erului era specificat „Linus Torvalds”, dar Linus nu le-a adăugat. De exemplu, sub numele lui Linus în ramura lui Kes a existat un commit care repeta un alt commit din ramura lui Linus, dar cu un alt hash SHA1. Ambele commit-uri arată identic, cu excepția informațiilor despre semnătură.
Modificările nu păreau a fi o eroare accidentală în timpul operației „git rebase”, deoarece conțineau informații incorecte despre autorul commit-ului. Linus Torvalds a considerat aceasta ca fiind semne ale unei activități potențial dăunătoare și a inițiat blocarea acceptării oricăror modificări din partea lui Kes, până la clarificarea motivelor acestor manevre și confirmarea faptului că sistemul lui Kes nu a fost compromis.
Kes a răspuns că nu înțelege cum a putut să se întâmple asta. Înainte de aceasta, el s-a confruntat cu probleme în timp ce încerca să unească câteva dintre ramurile sale git, după care a încercat să le rezolve cu operația „git rebase”, dar pare că acest lucru nu a ajutat. Toate acestea au avut loc pe fondul unei defecțiuni a unui SSD, care a generat erori în timpul copiei. Kes credea că după defecțiune a reușit să își restabilească starea repository-urilor, dar se pare că nu a fost așa. Pentru a restabili integritatea, Kes intenționează să recrieze ramurile sale din patch-uri separate. Ca fiind cea mai probabilă cauză a înlocuirii autorului, Kes consideră o încercare eșuată de a restaura repository-ul după deteriorarea sa.
Linus nu a fost mulțumit de această explicație, deoarece, în opinia sa, modificările istoricului commit-urilor în depozitul lui Kess semănau foarte mult cu acțiuni deliberate, nu cu o eroare întâmplătoare. Rebazarea istoricului modificărilor prin operația «git rebase» ar fi putut explica rescrierea autorului commit-ului, dar Linus nu înțelege cum o astfel de operație «git rebase» ar fi putut fi realizată din greșeală.
Rescrierea unuia sau două commit-uri ar putea fi justificată ca o greșeală, dar în depozitul lui Kess au fost rescrise peste șase mii de merge-commit-uri, dintre care în 330 autorul a fost indicat ca fiind Linus, deși aceste commit-uri nu au fost obținute din arborele git al lui Linus. Modificările efectuate semănă mai mult cu activitatea unui script decât cu rezultatul deteriorării informației pe stocare, deoarece acestea necesită recrearea separată a fiecărui commit.
Kess l-a asigurat pe Linus că nu a făcut acest lucru intenționat și că nu ar fi realizat astfel de experimente fără preaviz (de exemplu, experimentul anterior legat de generarea de coliziuni ale commit-urilor a fost convenit cu Linus). Săptămâna aceasta, el a efectuat câteva operații manuale în depozit și acum va încerca să înțeleagă ce a mers prost și să reproducă problema. De exemplu, Kess a efectuat o operație de rebase pentru arborii git for-next/hardening și for-linus/hardening, folosind, spre deosebire de transformările anterioare, ramura «master», nu rc2. În cadrul acestei operații, el a făcut modificări în scripturile pentru verificarea cererilor de push.
Addendum: Kess Cook a publicat un mesaj suplimentar, în care a afirmat că cel mai probabil problema a apărut din utilizarea utilitarului «git-filter-repo», care rescrie istoricul commit-urilor în depozit, în combinație cu comanda «b4 trailers», destinată obținerii și aplicării trailerelor la commit-uri (de exemplu, «Signed-off-by:».
Sursa: opennet.ro
