Få dage siden en usædvanlig hændelse indtraf, som rystede Linux-kernefællesskabet, og det er Linus Torvalds beordrede øjeblikkelig suspendering af Kees Cooks konto på kernel.org., efter at have detekteret eksistensen af manipulerede commits i denne udviklers Git-repository.
Kees Cook, anerkendt for sit lederskab i Ubuntus sikkerhedsteam og for at vedligeholde mere end et dusin sikkerhedsrelaterede undersystemer i kernen, blev midlertidigt forbudt at indsende ændringer, mens fakta blev afklaret.
Ændring af forfatterskab og signaturer i Kees Cook-arkivet
Problemet opstod som følge af en anmodning om ændring af inkorporering.s til 6.16-kernegrenen, hvor Linus identificerede referencer til et arkiv der indeholdt commits manipuleret med hans navn som forfatter og bekræfter, på trods af ikke selv at have udført dem. Et af de mest alvorlige eksempler var eksistensen af en duplikat-commit, identisk i indhold med originalen, men med en anden SHA1-hash, som fejlagtigt inkluderede Linus Torvalds' signatur.
Disse ændringer kunne ikke blot tilskrives en tilfældig fejll under en git rebase-operation, da de involverede massive ændringer af følsomme oplysninger, herunder over 6.000 omskrevne commits, hvoraf 330 havde Linus' navn som forfatter.
Torvalds' reaktion: mistanke om bevidst manipulation
Linus Torvalds skjulte ikke sin bekymring og beskrev begivenhederne som potentielt ondsindede:
"En eller to omskrivninger kunne være en fejl. Men tusindvis af dem, mange med min forfalskede underskrift, er det ikke," erklærede han.
I betragtning af ændringernes omfang og risikoen for integriteten af det officielle kernetræ, Torvalds spurgte Konstantin Ryabitsev, kernel.org infrastrukturadministrator, qat blokere Kees Cooks adgang, indtil situationen er afklaret.
Som svar, Kees Cook forklarede, at han for nylig havde haft tekniske problemer der kunne have udløst hændelsen. Han sagde, Dit SSD-drev oplevede fejl under kopiering, hvilket havde forårsaget beskadigelse i flere repositories. Efter disse fejl forsøgte han at gendanne status for sit repository ved hjælp af git rebase og forskellige automatiseringsværktøjer.
Disse operationer blev dog udført på kritiske grene, såsom for-next/hardening og for-linus/hardening, hvilket førte til en utilsigtet ændring af arkivets historik, herunder ændringen i forfatterskabet af commits. Trods sin forklaring var Linus skeptisk.:
"Jeg forstår ikke, hvordan en utilsigtet overhaling kan ske, og slet ikke med så mange omkørselsændringer."
Den virkelige synder: git-filter-repo og b4 trailere
I en senere besked, Kees Cook identificerede den sandsynlige kilde til fejlenkombineret brug af to værktøjer, git-filter-repo og b4 trailere, som manipulerer commit-historikken og trailere (tags som Signed-off-by:) i commits.
Denne forkerte brug af overskuddet ville have forårsaget automatisk omskrivning af tusindvis af commits, herunder at erstatte forfatteren med standardværdien (i dette tilfælde Linus Torvalds), uden at Kees bemærkede fejlen på det tidspunktKonstantin Ryabitsev, forfatteren af b4-værktøjet, bekræftede denne teori og hævdede, at Cook ikke havde nogen ondsindet hensigt. Faktisk genererede systemet allerede advarsler, der blev ignoreret.
Efter at situationen var blevet afklaret, blev Kees Cooks adgang til kernel.org genoprettet. Som en forebyggende foranstaltning er det blevet annonceret, at værktøjet b4 vil inkludere en ny sikkerhedskontrol, Dette vil forhindre ændring af commits, hvis forfatterskab ikke matcher den nuværende brugers identitet, fra nu af. Dette har til formål at forhindre lignende fejl og beskytte integriteten af kernens kildekode.
Kees lovede på sin side at genskabe de berørte grene. fra individuelle programrettelser og analysere i dybden de trin, der førte til fejlen. Selvom Hændelsen har forværret forholdet i holdet kerneudvikling har også fremhævet vigtigheden af at bruge historikomskrivningsværktøjer med forsigtighed, især i projekter så kritiske som Linux-kernen.
Endelig er det værd at nævne, at denne hændelse mellem Linus Torvalds og Kees Cook tjener som en advarsel om farerne ved at manipulere med commit-historikken, og at takket være den hurtige indgriben fra de ansvarlige for kernel.org og processens gennemsigtighed, situationen er blevet bragt under kontrol.
Endelig, hvis du er interesseret i at lære mere om det, kan du tjekke detaljerne i det følgende link.