{"id":125748,"date":"2025-06-01T15:05:12","date_gmt":"2025-06-01T13:05:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka"},"modified":"2025-06-01T15:05:12","modified_gmt":"2025-06-01T13:05:12","slug":"inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","title":{"rendered":"Incidente de substitui\u00e7\u00e3o de commits no branch do n\u00facleo Linux por Kesa Kuka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds exigiu que o administrador do kernel.org bloqueasse imediatamente a conta de Kesa Kuka, ex-administrador-chefe do kernel.org e l\u00edder da Ubuntu Security Team, respons\u00e1vel por 14 subsistemas relacionados \u00e0 seguran\u00e7a no n\u00facleo. Konstantin Ryabtsev, respons\u00e1vel pela infraestrutura do kernel.org, executou o bloqueio. O motivo do bloqueio foi um pull request para incluir altera\u00e7\u00f5es no branch do n\u00facleo 6.16, referindo-se a um reposit\u00f3rio git onde as informa\u00e7\u00f5es sobre a autoria de alguns commits foram modificadas. <\/p>\n
No reposit\u00f3rio git suportado por Kesa, foram feitas altera\u00e7\u00f5es fict\u00edcias, onde o campo do autor e do committer indicava 'Linus Torvalds', mas Linus n\u00e3o as adicionou. Por exemplo, sob o nome de Linus, havia um commit no branch de Kesa que repetia outro commit no branch de Linus, mas com um hash SHA1 diferente. Ambos os commits parecem id\u00eanticos, exceto pela informa\u00e7\u00e3o da assinatura. <\/p>\n
As altera\u00e7\u00f5es n\u00e3o pareciam um erro aleat\u00f3rio durante a opera\u00e7\u00e3o 'git rebase', pois continham informa\u00e7\u00f5es incorretas sobre o autor do commit. Linus Torvalds considerou isso como sinais de potencial atividade maliciosa e iniciou a proibi\u00e7\u00e3o de aceitar quaisquer altera\u00e7\u00f5es de Kesa at\u00e9 esclarecer as raz\u00f5es por tr\u00e1s de tais manipula\u00e7\u00f5es e confirmar que o sistema de Kesa n\u00e3o havia sido comprometido. <\/p>\n
Kesa respondeu que n\u00e3o entende como isso pode ter acontecido. Antes disso, ele enfrentou problemas ao tentar mesclar v\u00e1rios de seus branches git, depois tentou solucion\u00e1-los com a opera\u00e7\u00e3o 'git rebase', mas parece que isso n\u00e3o ajudou. Tudo isso ocorreu em meio a uma falha no SSD, que estava gerando erros durante a c\u00f3pia. Kesa acreditava que, ap\u00f3s a falha, conseguiu restaurar o estado de seus reposit\u00f3rios, mas aparentemente n\u00e3o foi isso que aconteceu. Para restaurar a integridade, Kesa pretende recriar seus branches a partir de patches individuais. Como a causa mais prov\u00e1vel da altera\u00e7\u00e3o do autor, Kesa considera uma tentativa malsucedida de recupera\u00e7\u00e3o do reposit\u00f3rio ap\u00f3s sua corrup\u00e7\u00e3o. <\/p>\n
Linus n\u00e3o ficou satisfeito com essa explica\u00e7\u00e3o, pois acreditava que as altera\u00e7\u00f5es no hist\u00f3rico de commits no reposit\u00f3rio de Kesa se assemelhavam muito a a\u00e7\u00f5es intencionais, e n\u00e3o a uma falha acidental. A rebase do hist\u00f3rico de altera\u00e7\u00f5es atrav\u00e9s da opera\u00e7\u00e3o 'git rebase' poderia explicar a regrava\u00e7\u00e3o do committer, mas Linus n\u00e3o consegue entender como tal opera\u00e7\u00e3o 'git rebase' poderia ter sido realizada por engano. <\/p>\n
Reescrever um ou dois commits ainda poderia ser atribu\u00eddo a um erro, mas no reposit\u00f3rio 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\u00e3o tenham sido obtidos da \u00e1rvore git de Linus. As mudan\u00e7as feitas se assemelham mais ao trabalho de um script do que ao resultado da corrup\u00e7\u00e3o de dados no armazenamento, pois exigem a recria\u00e7\u00e3o separada de uma c\u00f3pia de cada commit. <\/p>\n
Kes garantiu a Linus que n\u00e3o fez isso intencionalmente e que n\u00e3o realizaria tais experimentos sem aviso pr\u00e9vio (por exemplo, o experimento anterior sobre colis\u00f5es de commits foi acordado com Linus). Esta semana, ele realizou v\u00e1rias opera\u00e7\u00f5es manuais no reposit\u00f3rio e agora tentar\u00e1 entender o que deu errado e reproduzir o problema. Por exemplo, Kes executou uma opera\u00e7\u00e3o de rebase para as \u00e1rvores git for-next\/hardening e for-linus\/hardening, usando, ao contr\u00e1rio das transforma\u00e7\u00f5es semelhantes anteriores, a branch 'master', e n\u00e3o a rc2. Durante essa opera\u00e7\u00e3o, ele fez altera\u00e7\u00f5es nos scripts para verificar os pulls requests. <\/p>\n
Complemento: Kes Cook publicou mais uma mensagem, na qual afirmou que, muito provavelmente, o problema surgiu devido ao uso da ferramenta 'git-filter-repo', que realiza a reescrita do hist\u00f3rico de commits no reposit\u00f3rio, em combina\u00e7\u00e3o com o comando 'b4 trailers', que \u00e9 destinado a obter e aplicar trailers aos commits (por exemplo, 'Signed-off-by:'). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"