Linus Torvalds demanded that the administrator of kernel.org immediately block the account of Kesa Cook, the former chief sysadmin of kernel.org and leader of the Ubuntu Security Team, overseeing 14 security-related subsystems in the kernel. Konstantin Ryabcev, responsible for kernel.org's infrastructure, executed the block. The reason for the block was a pull request to include changes in the 6.16 kernel branch, referencing a git repository where the authorship information for some commits was altered.
In the git repository maintained by Kesa, there were fake changes where the author and committer fields were attributed to 'Linus Torvalds', but Linus did not add them. For example, under Linus's name in Kesa's branch, there was a commit that duplicated another commit in Linus's branch but with a different SHA1 hash. Both commits appeared identical except for the signature information.
The changes did not resemble a random error during the 'git rebase' operation since they contained incorrect authorship information for the commit. Linus Torvalds considered this indicative of potentially malicious activity and initiated a block on accepting any changes from Kesa until the reasons for such manipulations were clarified and it was confirmed that Kesa's system had not been compromised.
Kesa responded that he did not understand how this could have happened. Previously, he had encountered issues when trying to merge several of his git branches and then attempted to resolve them using the 'git rebase' operation, but it seemed this did not help. All of this occurred against the backdrop of an SSD failure that was generating errors during copying. Kesa believed that he had managed to restore the state of his repositories after the failure, but apparently, this was not the case. To restore integrity, Kesa intends to recreate his branches from separate patches. He considers the most likely cause of the authorship substitution to be an unsuccessful attempt to restore the repository after it was corrupted.
Linus was not satisfied with such an explanation, as he believes the changes in the commit history of Kess's repository resemble intentional actions rather than an accidental failure. The rebasing of the change history with the 'git rebase' operation could explain the rewriting of the committer, but Linus cannot understand how such a 'git rebase' operation could have been executed by mistake.
Rewriting one or two commits could still be attributed to an error, but in Kess's repository, over six thousand merge commits were rewritten, of which Linus was listed as the author in 330, even though those commits were not obtained from Linus's git tree. The changes performed are more reminiscent of a script's actions than a result of data corruption on the storage, as they require a separate recreation of each commit copy.
Kess assured Linus that he did not do this intentionally and would not conduct such experiments without warning (for example, a previous experiment on invoking commit collisions was agreed upon with Linus). This week he performed several manual operations with the repository and is now trying to figure out what went wrong and reproduce the issue. For instance, Kess carried out a rebase operation for the git trees for-next/hardening and for-linus/hardening, using the 'master' branch instead of rc2, unlike previous similar transformations. During this operation, he made changes to the scripts for checking push requests.
Addition: Kess Cook posted another message stating that the issue likely arose from using the 'git-filter-repo' utility, which rewrites the commit history in the repository, combined with the 'b4 trailers' command, intended for obtaining and applying trailers to commits (for example, 'Signed-off-by:').
Source: opennet.ru
