[NOTÍCIA] Linus Torvalds barra PR por adulteração de árvore de commits

Linus Torvalds, pai do Linux e do Git, se irritou com um pull request feito por Kees Cook, desenvolvedor veterano do kernel do Linux.

Confira a mensagem enviada por Linus em 31-05-2025 como resposta ao pull request:

WTF, Kees? Você parece ter ativamente e maliciosamente modificado sua árvore por completo. Existem commits totalmente malucos ali que são absolutamente falsos. Você tem isso: f8b59a0f90a2 Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core que alega ter sido feito por mim, e comitado por mim, mas definitivamente não foi. É algum lixo que você inventou. Sim, houve um commit de verdade igual a esse, mas ele tem o SHA1 ID de 9d230d500b0e. E isso não é só algum erro inocente de rebase, porque está mentindo ativamente sobre quem fez o commit. Isso é completamente inaceitável. A partir de agora, me recuso a puxar qualquer coisa de você até que consiga explicar que #$&*! você andou fazendo, porque isso faz parecer que você esteve ativamente fazendo coisa errada. Você precisa implodir essa árvore, e arranjar uma boa explicação pra esse tipo de porcaria. Estou copiando o Konstantin, porque realmente considero que esses joguinhos são COMPLETAMENTE INACEITÁVEIS, e esse não é um comportamento que podemos tolerar em contas kernel.org. Konstantin - por favor suspenda a conta do Kees imediatamente até que isso seja esclarecido. Porque parece malicioso. Linus

Kees Cook se defendeu, alegando que sofreu uma falha de SSD e que estava tendo problemas com merges, e que provavelmente suas tentativas de rebase causaram os erros apontados por Torvalds. No entanto, Linus insistiu que isso não seria capaz de explicar a falsa autoria atribuída a inúmeros commits.

Finalmente, Kees admitiu que foi descuidado ao tentar reconstruir as árvores sem dar atenção aos warnings das suas ferramentas, e forneceu uma maneira de replicar o problema usando a seguinte sequência de comandos:

This shows the same problem (using Linus's tree and linux-next):

$ git checkout 9d230d500b0e -b test/repro/before $ git cherry-pick 368556dd234d $ git cherry-pick eef1355c269b $ b4 trailers -u https://lore.kernel.org/all/CANpmjNPpyJn++DVZmO89ms_HkJ0OvQzkps0GjCFbWkk0F+_8Xg@mail.gmail.com

No final, a culpa foi atribuída a um "abuso" do git-filter-repo cometido pelo comando trailers do utilitário clássico de patching b4. A conta kernel.org de Kees Cook foi reativada.

Para evitar que o problema se repita, Konstantine Ryabitsev recomendou:

Até eu conseguir corrigir isso, sugiro que sempre use b4 trailers -u com a flag --since-commit, para restringir o escopo da alteração. (...) O problema teria sido evitado restringindo os commits da operação apenas aos que foram cherry-picked dos últimos merges do Linus.

O próprio Linus fez um apelo a Konstantine a fim de que o comportamento do b4 seja revisado:

Então o perigo real é mentir sobre as informações de quem fez o commit. É isso que nenhuma ferramenta padrão deveria jamais fazer, e o que me deixou tão irritado. Konstantin, pode por favor consertar o b4 para que nunca, nunca reescreva um commit com informações que não sejam as do usuário atual?

Depois dos esclarecimentos, Konstantine concordou em acrescentar a verificação solicitada por Linus ao b4 e deixou sua reflexão sobre como as coisas acabaram chegando nesse ponto:

Está funcionando conforme projetado, lamento dizer -- git-filter-repo é uma ferramenta poderosa para reescrever o histórico do git e irá alegremente disparar mesmo se você estiver mirando nos próprios pés.

Link para o início da discussão: https://lore.kernel.org/all/CAHk-=wj4a_CvL6-=8gobwScstu-gJpX4XbX__hvcE=e9zaQ_9A@mail.gmail.com/

Créditos do furo de reportagem: SavvyNik https://www.youtube.com/watch?v=Zu42F-XMNC4

Novo vídeo do SavvyNik sobre o tema: https://youtu.be/NnrMmq8Sf44?si=EMgVff2kl5-iS_Vc&utm_source=MTQxZ