Linus Torvalds požádal správce kernel.org, aby okamžitě zablokoval účet Kesa Kuka, bývalého hlavního administrátora kernel.org a vedoucího Ubuntu Security Team, který spravoval 14 podsystemů týkajících se zabezpečení v jádře. Konstantin Rjabtsev, zodpovědný za provoz infrastruktury kernel.org, provedl blokaci. Důvodem pro blokaci byl pull request na zařazení změn do větve jádra 6.16, který odkazoval na git repository, v němž byla změněna informace o autorství některých commitů.
Ve Kese podporovaném git repository byly přítomny falešné změny, v poli autora a committera byla uvedena „Linus Torvalds“, ale Linus je nepřidal. Například pod jménem Linuse ve Kesi existoval commit, který opakoval jiný commit ve větvi Linuse, ale s jiným SHA1 hashem. Oba commity vypadají stejně, kromě informací o podpisu.
Změny se nezdály být náhodnou chybou při provádění operace „git rebase“, protože obsahovaly nesprávné informace o autorovi commitu. Linus Torvalds to považoval za stopy potenciálně škodlivé aktivity a zahájil blokaci přijímání jakýchkoli změn od Kesa, dokud se neobjasní příčiny takových manipulací a nepotvrdí, že systém Kesa nebyl kompromitován.
Kes odpověděl, že nerozumí, jak k tomu mohlo dojít. Předtím se setkal s problémy při pokusu o sloučení několika svých git větví, po čemž se pokusil je vyřešit operací „git rebase“, ale zřejmě to nepomohlo. To vše se odehrávalo na pozadí selhání SSD disku, který hlásil chyby během kopírování. Kes měl za to, že po selhání se podařilo obnovit stav jeho repository, ale soudě podle všeho tomu tak není. K obnovení integrity se Kes chystá přepracovat své větve z jednotlivých patchů. Jako nejpravděpodobnější příčinu podvržení autora Kes považuje neúspěšný pokus o obnovu repository po jejím poškození.
Linus nebyl spokojen s takovým vysvětlením, protože dle jeho názoru změny historie commitů v Kessově repozitáři velmi připomínají záměrné jednání, nikoli náhodnou chybu. Přehazování historie změn pomocí příkazu „git rebase“ by mohlo vysvětlit přepísání committera, ale Linus nemůže pochopit, jak mohla být taková operace „git rebase“ provedena omylem.
Přepsání jednoho nebo dvou commitů by se ještě dalo považovat za chybu, ale v Kessově repozitáři bylo přepsáno více než šest tisíc merge commitů, z nichž v 330 byl autorem Linus, přičemž tyto commity nebyly získány z git stromu Linuse. Provedené změny více připomínají práci skriptu než výsledek poškození informací na disku, neboť vyžadují samostatné obnovení každého commitu.
Kess ujistil Linuse, že to neudělal úmyslně a že by takové experimenty neprováděl bez varování (například předchozí experiment s vyvoláním kolizí commitů byl s Linusem dohodnut). Tento týden vykonal několik ručních operací s repozitářem a nyní se pokusí zjistit, co se pokazilo, a reprodukovat problém. Například Kess provedl operaci rebase pro git stromy for-next/hardening a for-linus/hardening, přičemž na rozdíl od předchozích podobných transformací použil větev „master“ namísto rc2. Během této operace prováděl změny v skriptech pro kontrolu push požadavků.
Doplňující informace: Kess Cook zveřejnil další zprávu, ve které uvedl, že pravděpodobně problém vznikl použitím nástroje „git-filter-repo“, který provádí přepisování historie commitů v repozitáři, v kombinaci s příkazem „b4 trailers“, určeným pro získání a aplikaci trailerů na commity (například „Signed-off-by:“).
Zdroj: opennet.ru
