Linus Torvalds exigiu que o administrador do kernel.org bloqueasse imediatamente a conta de Kesa Kuka, ex-administrador-chefe do kernel.org e líder da Ubuntu Security Team, responsável por 14 subsistemas relacionados à segurança no núcleo. Konstantin Ryabtsev, responsável pela infraestrutura do kernel.org, executou o bloqueio. O motivo do bloqueio foi um pull request para incluir alterações no branch do núcleo 6.16, referindo-se a um repositório git onde as informações sobre a autoria de alguns commits foram modificadas.
No repositório git mantido por Kesa, havia alterações fictícias nos campos de autor e committer, que tinham «Linus Torvalds» como autor, mas Linus não as adicionou. Por exemplo, havia um commit sob o nome de Linus no branch de Kesa que replicava outro commit no branch de Linus, mas com um hash SHA1 diferente. Ambos os commits pareciam idênticos, exceto pela informação da assinatura.
As alterações não pareciam um erro acidental durante a operação «git rebase», pois continham informações incorretas sobre o autor do commit. Linus Torvalds considerou isso uma possível atividade maliciosa e iniciou o bloqueio da aceitação de quaisquer alterações de Kesa, até que se esclarecessem as razões por trás dessas manipulações e se confirmasse que o sistema de Kesa não estava comprometido.
Kesa respondeu que não entende como isso pôde acontecer. Antes disso, ele enfrentou problemas ao tentar combinar vários de seus branches git, após o que tentou resolvê-los com a operação «git rebase», mas aparentemente isso não ajudou. Tudo isso ocorreu em meio a uma falha no SSD, que apresentava erros durante a cópia. Kesa acreditava que, após a falha, havia conseguido restaurar o estado de seus repositórios, mas aparentemente não foi o caso. Para restaurar a integridade, Kesa pretende recriar seus branches a partir de patches individuais. Como a causa mais provável da alteração de autoria, Kesa considera uma tentativa malsucedida de recuperar o repositório após o dano.
Linus não ficou satisfeito com essa explicação, pois, em sua opinião, as alterações na história dos commits no repositório de Kess são muito semelhantes a ações intencionais, e não a uma falha acidental. Um rebase da história das mudanças usando o comando "git rebase" poderia justificar a reescrita do commit, mas Linus não consegue entender como tal operação "git rebase" poderia ter sido executada por engano.
Reescrever um ou dois commits ainda poderia ser atribuído a um erro, mas no repositório de Kess, mais de seis mil commits de merge foram reescritos, dos quais em 330 Linus foi indicado como autor, mesmo que esses commits não tenham sido obtidos da árvore git de Linus. As mudanças feitas se assemelham mais ao trabalho de um script do que ao resultado da corrupção de dados no armazenamento, pois exigem a recriação separada de uma cópia de cada commit.
Kess assegurou a Linus que não fez isso de propósito e que não realizaria tais experimentos sem aviso prévio (por exemplo, o experimento anterior sobre colisões de commits foi aprovado por Linus). Esta semana, ele estava realizando várias operações manuais no repositório e agora tentará entender o que deu errado e reproduzir o problema. Por exemplo, Kess executou a operação de rebase para as árvores git for-next/hardening e for-linus/hardening, utilizando, ao contrário de transformações anteriores, a branch "master" em vez de rc2. Durante essa operação, ele fez alterações em scripts para verificar pull requests.
Adendo: Kess Cook publicou outra mensagem na qual afirmou que, provavelmente, o problema surgiu devido ao uso da ferramenta "git-filter-repo", que reescreve a história dos commits no repositório, em combinação com o comando "b4 trailers", destinado a obter e aplicar trailers a commits (por exemplo, "Signed-off-by:").
Fonte: opennet.ru
