Linus Torvalds je po odkritju sumljivih sprememb odredil blokado Keesa Cooka 

Linus Torvalds v Con

Pred nekaj dnevi zgodil se je nenavaden dogodek, ki je pretresel skupnost jedrcev Linuxa, in to je Linus Torvalds je odredil takojšnjo blokado računa Keesa Cooka na kernel.org., po zaznavi obstoja manipuliranih zapisov v repozitoriju Git tega razvijalca.

Kees Cook, priznan po svojem vodstvu v varnostni ekipi Ubuntuja in za vzdrževanje več kot ducata varnostnih podsistemov jedra, je bilo začasno prepovedano oddati spremembe, medtem ko se dejstva razjasnijo.

Sprememba avtorstva in podpisov v repozitoriju Kees Cook

Težava je nastala zaradi zahteve za vključitev sprememb.s do veje jedra 6.16, v katerem je Linus prepoznal reference na repozitorij ki je vseboval zaveze, manipulirane z njegovo ime kot avtorja in potrjevalca, čeprav jih sam ni naredil. Eden najresnejših primerov je bil obstoj podvojenega zapisa (commit), ki je bil po vsebini enak originalu, vendar z drugačno SHA1 zgoščeno vrednostjo, in je lažno vključeval podpis Linusa Torvaldsa.

Te spremembe ni bilo mogoče pripisati zgolj naključni napakimed operacijo ponovne baze gita, ker so vključevale obsežne modifikacije občutljivih informacij, vključno z več kot 6.000 prepisanimi commit-i, od katerih jih je bilo 330 avtorjev Linusovo ime.

Torvaldsova reakcija: sumi namerne manipulacije

Linus Torvalds ni skrival svoje zaskrbljenosti in dogodke opisal kot potencialno zlonamerne:

»Ena ali dve prepisi bi lahko bili napaka. Toda na tisoče jih je, mnogi z mojim ponarejenim podpisom, niso,« je izjavil.

Glede na obseg sprememb in tveganje za integriteto uradnega drevesa jedra, Torvalds je vprašal Konstantina Rjabitseva, skrbnik infrastrukture kernel.org, qblokirati dostop Keesa Cooka, dokler se situacija ne razjasni.

V odgovor, Kees Cook je pojasnil, da je imel v zadnjem času tehnične težave to bi lahko sprožilo incident. Rekel je, Med kopiranjem je na vašem SSD disku prihajalo do napak, ki so povzročile poškodbo v več repozitorijih. Po teh napakah je poskušal obnoviti stanje svojega repozitorija z uporabo ukaza git rebase in različnih orodij za avtomatizacijo.

Vendar so bile te operacije izvedene na kritičnih vejah, kot sta for-next/hardening in for-linus/hardening, kar je privedlo do nenamerne spremembe zgodovine repozitorija, vključno s spremembo avtorstva zapisov (commitov). Kljub njegovi razlagi je bil Linus skeptičen.:

"Ne razumem, kako je lahko prišlo do nenamernega prehitevanja, kaj šele s tolikšnim številom sprememb."

Pravi krivec: napovedniki git-filter-repo in b4

V kasnejšem sporočilu, Kees Cook je ugotovil verjeten vir napake: kombinirana uporaba dveh orodij, git-filter-repo in b4 trailerji, ki manipulirajo z zgodovino zapisov in napovednike (oznake kot je Signed-off-by:) v commitih.

Ta napačna uporaba dobička bi povzročilo samodejno prepisovanje tisočih commitov, vključno z zamenjavo avtorja s privzeto vrednostjo (v tem primeru Linus Torvalds), ne da bi Kees takrat opazil napakoKonstantin Rjabicev, avtor orodja b4, je to teorijo potrdil in zatrdil, da Cook ni imel nobenega zlonamernega namena. Pravzaprav je sistem že ustvarjal opozorila, ki so bila prezrta.

Potem ko so se razmere razjasnile, je bil Keesu Cooku ponovno omogočen dostop do kernel.org. Kot preventivni ukrep je bilo napovedano, da orodje b4 bo vključeval novo varnostno preverjanje, To bo od zdaj naprej preprečilo spreminjanje zapisov (commit), katerih avtorstvo se ne ujema z identiteto trenutnega uporabnika. Namen tega je preprečiti podobne napake in zaščititi integriteto izvorne kode jedra.

Kees se je s svoje strani zavezal, da bo poustvaril prizadete veje. iz posameznih popravkov in podrobno analizirati korake, ki so privedli do napake. Čeprav Incident je zaostril odnose v ekipi razvoj jedra je prav tako poudaril pomen previdnosti pri uporabi orodij za prepisovanje zgodovine, zlasti pri tako ključnih projektih, kot je jedro Linuxa.

Nazadnje je treba omeniti, da ta incident med Linusom Torvaldsom in Keesom Cookom služi kot opozorilo o nevarnostih manipuliranja z zgodovino zapisov in da zahvaljujoč hitremu posredovanju od tistih, ki so odgovorni za kernel.org in preglednost procesa, situacija je bila pod nadzorom.

Če vas zanima več o tem, si lahko podrobnosti ogledate v nadaljevanju povezavo


Dodaj kot prednostni vir v Googlu