Linus Torvalds a demandé à l'administrateur de kernel.org de bloquer immédiatement le compte de Kesa Cook, l'ancien administrateur système de kernel.org et responsable de l'Ubuntu Security Team, qui s'occupait de 14 sous-systèmes liés à la sécurité dans le noyau. Konstantin Ryabtsev, responsable de l'infrastructure de kernel.org, a effectué le blocage. Le motif du blocage était un pull request visant à intégrer dans la branche du noyau 6.16 des modifications se référant à un dépôt git où les informations d'auteur de certains commits avaient été modifiées.
Le dépôt git, maintenu par Kesa, contenait des modifications fictives, où dans le champ auteur et committer figurait «Linus Torvalds», mais Linus ne les avait pas ajoutées. Par exemple, sous le nom de Linus dans la branche de Kesa se trouvait un commit qui répétait un autre commit dans la branche de Linus, mais avec un autre hash SHA1. Les deux commits semblent identiques, sauf pour les informations sur la signature.
Les modifications ne ressemblaient pas à une erreur accidentelle lors d'une opération de «git rebase», car elles contenaient des informations incorrectes sur l'auteur du commit. Linus Torvalds a considéré cela comme des traces d'une activité potentiellement malveillante et a initié un blocage de l'acceptation de toute modification de Kesa, jusqu'à ce que les raisons de telles manipulations soient clarifiées et que l'on confirme que le système de Kesa n'avait pas été compromis.
Kesa a répondu qu'il ne comprend pas comment cela a pu se produire. Auparavant, il avait rencontré des problèmes lors de la tentative de fusion de plusieurs de ses branches git, après quoi il a essayé de les résoudre avec une opération de «git rebase», mais cela semble n'avoir pas aidé. Tout cela se produisait sur fond de défaillance du disque SSD, qui produisait des erreurs lors des copies. Kesa pensait qu'après la panne, il avait réussi à restaurer l'état de ses dépôts, mais apparemment ce n'est pas le cas. Pour restaurer l'intégrité, Kesa prévoit de recréer ses branches à partir de patches distincts. Comme cause la plus probable du changement d'auteur, Kesa considère une tentative infructueuse de restauration de son dépôt après un endommagement.
Linus n'a pas été satisfait de cette explication, car selon lui, les modifications de l'historique des commits dans le dépôt de Kess ressemblent beaucoup plus à des actions intentionnelles qu'à une erreur aléatoire. La rebase de l'historique des modifications avec l'opération « git rebase » aurait pu expliquer la réécriture du commit, mais Linus ne comprend pas comment une telle opération « git rebase » a pu être effectuée par erreur.
La réécriture d'un ou deux commits aurait encore pu être considérée comme une erreur, mais plus de six mille commits de fusion ont été réécrits dans le dépôt de Kess, dont 330 avaient Linus comme auteur, alors que ces commits n'étaient pas issus de l'arbre git de Linus. Les modifications effectuées ressemblent davantage au travail d'un script qu'à un résultat de corruption d'informations sur le support, car elles nécessitent la recréation séparée de chaque commit.
Kess a assuré à Linus qu'il ne l'avait pas fait intentionnellement et qu'il n'aurait pas conduit ce genre d'expérimentations sans prévenir (par exemple, l'expérimentation précédente concernant les collisions de commits avait été convenue avec Linus). Cette semaine, il a effectué plusieurs opérations manuelles sur le dépôt et va maintenant essayer de comprendre ce qui a mal tourné et de reproduire le problème. Par exemple, Kess a effectué une opération de rebase pour les arbres git for-next/hardening et for-linus/hardening, utilisant, contrairement aux transformations précédentes, la branche « master » au lieu de rc2. Dans le cadre de cette opération, il a apporté des modifications aux scripts de vérification des demandes de fusion.
Complément : Kess Cook a publié un autre message indiquant que le problème est probablement dû à l'utilisation de l'outil « git-filter-repo », qui réécrit l'historique des commits dans le dépôt, en conjonction avec la commande « b4 trailers », destinée à obtenir et appliquer des trailers aux commits (par exemple, « Signed-off-by: »).
Source : opennet.ru
