because this days it is very simple to translate every language even without google

blog.desdelinux.net
Linus Torvalds order to block the Kees Cook's account after the detection of syuspicioiuus alterations
Darkcrizt

A few days ago, an unusual incident occurred, which shook the Linux kernel community, and Linus Torvalds ordered the immediate blocking of Kees Cook's account at kernel.org, after detecting the existence of manipulated commits in this developer's Git repository.

Kees Cook, renowned for his leadership in Ubuntu's security team and for maintaining more than a dozen subsystems related to the safety of the Kernel, was temporarily banned from sending changes while the facts were clarified.
Alteration of authors and signatures in Kees Cook's repository

The problem was generated by a request for incorporation of change into the branch of the kernel 6.16, in which Linus identified references to a repository containing commits manipulated with his name as author and confirmer, despite not having made them. One of the most serious examples was the existence of a duplicate commit, identical in content to the original but with a different SHA1 hash, which falsely included the firm of Linus Torvalds.

These changes could not simply be attributed to an accident error during a git rebarate operation, as they involved the massive modification of sensitive information, including more than 6,000 rewritten confirmations, 330 of which bore Linus's name as author.
Torvalds' reaction: suspicions of deliberate manipulation

Linus Torvalds did not hide his concern and described the facts as potentially malicious:

One or two rewrites could be a mistake. But thousands of them, many with my forged signature, are not," he said. 

In response, Kees Cook explained that he had had recent technical problems that could have triggered the incident. His SSD unit reportedly had failures during copy operations, which had caused corruption in several repositories. After those mistakes, he tried to recover the status of his repository using redoor git and various automation tools.

However, these operations were carried out on critical branches, such as for-next/hardening and for-linus/hardening, which led to an accidental modification of the history of the repository, including the change in the authorship of commits. Despite his explanation, Linus was skeptical:

I don't understand how you can do an accidental overrun, let alone with this volume of alterations.

In a later message, Kees Cook identified the likely source of the error: the combined use of two tools, git-filter-repo and b4 trailers, which manipulate the history of confirmations and trailers (labels as -off-by:) in commits.

This improper use of the utilities would have caused automatic rewriting of thousands of confirmations, including the author's replacement with the default value (in this case, Linus Torvalds), without Kees warning of the error at the time. Konstantin Ryabitsev, author of the b4 tool, confirmed this theory and assured that there was no malicious intention on Cook's part. In fact, the system was already generating warnings that were ignored.

After the situation was clarified, Kees Cook's access to kernel.org was restored. As a preventive measure, it has been announced that tool b4 will include a new security check, which will henceforth prevent the modification of commits whose author does not coincide with the identity of the current user. This seeks to prevent similar errors and protect the integrity of the kernel source code.

Kees, for his part, pledged to recreate the affected branches from individual patches and analyze in depth the steps that led to the error. While the incident has strained relations within the kernel development team, it has also highlighted the importance of cautiously using history rewriting tools, especially in projects as critical as the Linux core.

Finally, it should be mentioned that this incident between Linus Torvalds and Kees Cook serves as a warning about the dangers of manipulating the commissioning record and that thanks to the rapid intervention of the kernel.org officials and the transparency of the process, the situation has been controlled.

Finally, if you are interested in being able to know more about it, you can consult the details in the following link.