Linus Torvalds kërkoi nga administratori i kernel.org që të bllokonte menjëherë llogarinë e Kesa Kuk, ish-administratorit kryesor të kernel.org dhe liderit të Ubuntu Security Team, i cili mbante në bërthamë 14 nën-sisteme të lidhura me sigurinë. Konstantin Ryabtsev, përgjegjës për infrastrukturën e kernel.org, e realizoi bllokimin. Shkaku i bllokimit ishte një pull request për të përfshirë në degën e bërthamës 6.16 ndryshime që referoheshin në një git-repozitor, ku ishte ndryshuar informacioni mbi autorësinë e disa komiteteve.
Në git-repozitorin e mbështetur nga Kesi kishte modifikime të rreme, ku në fushën e autorit dhe komitit ishte përmendur 'Linus Torvalds', por Linus nuk i kishte shtuar ato. Për shembull, nën emrin e Linusit në degën e Kësit kishte një komit që përsëritej nga një komit tjetër në degën e Linusit, por me një hash të ndryshëm SHA1. Të dy komitet e duken të njëjtë, përveç informacionit mbi nënshkrimin.
Ndryshimet nuk i ngjanin një gabimi të rastësishëm gjatë operacionit 'git rebase', pasi përmbanin informacion të gabuar mbi autorin e komitit. Linus Torvalds e konsideroi këtë si shenja të aktivitetit potencialisht të dëmshëm dhe iniciatoi bllokimin e pranimit të çdo ndryshimi nga Kesi, derisa të zbardheshin arsyet për këto manovra dhe të konfirmohej se sistemi i Kësit nuk ishte komprometuar.
Kesi u përgjigj se nuk e kupton se si mund të kishte ndodhur kjo. Më parë, ai ishte përballur me probleme gjatë përpjekjeve për të bashkuar disa nga degët e tij git, pas së cilës përpiqej t'i zgjidhte ato me operacionin 'git rebase', por duket se kjo nuk ndihmoi. I gjithë ky proces ndodhte në një kontekst të dështimit të SSD-së, e cila po jepte gabime gjatë kopjimit. Kesi mendonte se pas dështimit kishte arritur të rikthente gjendjen e repozitoreve të tij, por duket se nuk ishte kështu. Për të rikthyer integritetin, Kesi ka në plan të riparojë degët e tij nga patch-e të veçanta. Si shkak më të mundshëm të ndërrimit të autorit, Kesi e shikon një përpjekje të dështuar për të rikthyer repozitorin pas dëmtimit.
Linus was not satisfied with such an explanation, as he believed that the changes in the commit history of Kess's repository resemble intentional actions rather than an accidental failure. Rebasing the change history with the "git rebase" operation could explain the re-recording of the committer, but Linus cannot understand how such a "git rebase" operation could have been performed by mistake.
Rewriting one or two commits could still be attributed to an error, but more than six thousand merge commits were rewritten in Kess's repository, out of which Linus was listed as the author in 330, despite the fact that these commits were not obtained from Linus's git tree. The changes made resemble the work of a script more than the result of information damage on the storage device, as they require separately recreating a copy of each commit.
Kess assured Linus that he did not do this on purpose and would not conduct such experiments without prior notice (for example, the previous experiment to trigger commit collisions was agreed upon with Linus). This week he performed several manual operations with the repository and will now try to figure out what went wrong and reproduce the problem. For instance, Kess executed a rebase operation for the git trees for-next/hardening and for-linus/hardening, using the "master" branch rather than rc2, contrary to previous similar transformations. During this operation, he made changes to scripts for checking push requests.
Additional: Kess Cook published another message stating that the problem likely arose from using the "git-filter-repo" utility, which rewrites commit history in the repository, in conjunction with the "b4 trailers" command, which is designed to retrieve and apply trailers to commits (for example, "Signed-off-by:").
Burimi: opennet.ru
