Incidenten med ersättningen av commits i Linux-kärnans gren av Kesa Cook

Linus Torvalds krävde att administratören för kernel.org omedelbart skulle blockera kontot för Kesa Cook, den tidigare huvudsystemadministratören för kernel.org och ledaren för Ubuntu Security Team, som ansvarade för 14 säkerhetsrelaterade delsystem i kärnan. Konstantin Ryabtsev, som ansvarade för infrastrukturen på kernel.org, genomförde blockeringen. Anledningen till blockeringen var en pull-begäran om att inkludera ändringar i kärnans gren 6.16, som hänvisade till ett git-förråd där informationen om författarskap för vissa commit hade förändrats.

I det git-förråd som Kesa stödde fanns det falska ändringar, där författar- och committerfältet angav 'Linus Torvalds', men Linus hade inte lagt till dem. Till exempel fanns det en commit under Linus namn i Kesa gren som upprepade en annan commit i Linus gren, men med en annan SHA1-hash. Båda commits såg lika ut, förutom informationen om signaturen.

Ändringarna verkade inte vara ett slumpmässigt misstag vid utförandet av kommandot 'git rebase', eftersom de innehöll felaktig information om commit-författaren. Linus Torvalds ansåg detta vara tecken på potentiellt skadlig aktivitet och initierade blockeringen av alla ändringar från Kesa tills orsaken till sådana manipulationer kunde klarläggas och att det bekräftades att Kessas system inte hade blivit komprometterat.

Kesa svarade att han inte förstod hur detta kunde ha hänt. Tidigare hade han haft problem med att försöka slå samman flera av sina git-grenar, och efter det hade han försökt lösa dem med kommandot 'git rebase', men det hjälpte tydligen inte. Allt detta skedde mot bakgrund av ett SSD-fel, som gav fel när det kopierade data. Kesa trodde att han efter felet hade lyckats återställa tillståndet på sina förråd, men tydligen var detta inte fallet. För att återställa integriteten planerar Kesa att återskapa sina grenar från separata patches. Som den mest sannolika orsaken till den uppkomna författarändringen anser Kesa att det handlade om ett misslyckat försök att återställa förrådet efter att det hade skadats.

Linus var inte nöjd med denna förklaring, eftersom han ansåg att förändringarna i commit-historiken i Kess repository liknar avsiktliga handlingar snarare än ett slumpmässigt fel. Omstrukturering av ändringshistoriken med hjälp av "git rebase" kunde ha förklarat commit-överskrivningen, men Linus kan inte förstå hur en sådan "git rebase"-åtgärd kunde ha utförts av misstag.

Att överskriva en eller två commits kunde fortfarande avskrivas som ett misstag, men i Kess repository hade mer än sex tusen merge-commits skrivits om, varav 330 hade Linus som författare, trots att dessa commits inte hade erhållits från Linus git-träd. De gjorda ändringarna påminner mer om ett skriptarbete än om ett resultat av skadad information på lagringsenheten, eftersom de kräver en separat återskapning av varje commit.

Kes försäkrade Linus om att han inte gjorde detta avsiktligt och skulle inte ha genomfört sådana experiment utan förvarning (till exempel, det tidigare experimentet med att åstadkomma commit-kollisioner var överenskommet med Linus). Denna vecka utförde han flera manuella operationer med repositoryt och kommer nu att försöka förstå vad som gick fel och återskapa problemet. Till exempel utförde Kes en rebase-operation för git-träden for-next/hardening och for-linus/hardening, där han, till skillnad från tidigare liknande transformationer, använde "master"-grenen istället för rc2. Under denna operation gjorde han ändringar i skripten för att kontrollera push-begärningar.

Tillägg: Kes Cook publicerade ett ytterligare meddelande där han uppgav att problemet troligtvis uppstod på grund av användning av verktyget "git-filter-repo", som utför överskrivning av commit-historik i repositoryt, i kombination med kommandot "b4 trailers", som är avsett för att hämta och tillämpa trailers på commits (till exempel "Signed-off-by:").

Källa: opennet.ru