Linus Torvalds a demand\u00e9 \u00e0 l'administrateur de kernel.org de bloquer imm\u00e9diatement le compte de Kesa Cook, l'ancien administrateur syst\u00e8me de kernel.org et responsable de l'Ubuntu Security Team, qui s'occupait de 14 sous-syst\u00e8mes li\u00e9s \u00e0 la s\u00e9curit\u00e9 dans le noyau. Konstantin Ryabtsev, responsable de l'infrastructure de kernel.org, a effectu\u00e9 le blocage. Le motif du blocage \u00e9tait un pull request visant \u00e0 int\u00e9grer dans la branche du noyau 6.16 des modifications se r\u00e9f\u00e9rant \u00e0 un d\u00e9p\u00f4t git o\u00f9 les informations d'auteur de certains commits avaient \u00e9t\u00e9 modifi\u00e9es. <\/p>\n
Dans le d\u00e9p\u00f4t git pris en charge par Kess, il y avait des modifications fictives, o\u00f9 le champ de l'auteur et du committer mentionnait \u00ab Linus Torvalds \u00bb, mais Linus ne les avait pas ajout\u00e9es. Par exemple, sous le nom de Linus dans la branche de Kess, il y avait un commit qui r\u00e9p\u00e9tait un autre commit dans la branche de Linus, mais avec un autre hachage SHA1. Les deux commits se ressemblent, sauf pour les informations de signature. <\/p>\n
Les modifications ne ressemblaient pas \u00e0 une simple erreur lors de l'ex\u00e9cution de l'op\u00e9ration \u00ab git rebase \u00bb, car elles contenaient de fausses informations sur l'auteur du commit. Linus Torvalds a consid\u00e9r\u00e9 cela comme des signes d'une activit\u00e9 potentiellement malveillante et a initi\u00e9 le blocage de toute acceptation de modifications de Kess jusqu'\u00e0 ce que les raisons de telles manipulations soient clarifi\u00e9es et que le syst\u00e8me de Kess soit confirm\u00e9 comme non compromis. <\/p>\n
Kess a r\u00e9pondu qu'il ne comprenait pas comment cela avait pu se produire. Auparavant, il avait rencontr\u00e9 des probl\u00e8mes en essayant de fusionner plusieurs de ses branches git, apr\u00e8s quoi il a essay\u00e9 de les r\u00e9soudre par l'op\u00e9ration \u00ab git rebase \u00bb, mais cela ne semblait pas avoir aid\u00e9. Tout cela se produisait sur fond de d\u00e9faillance d'un SSD, qui produisait des erreurs lors de la copie. Kess pensait qu'apr\u00e8s la d\u00e9faillance, il avait r\u00e9ussi \u00e0 restaurer l'\u00e9tat de ses d\u00e9p\u00f4ts, mais apparemment ce n'\u00e9tait pas le cas. Pour restaurer l'int\u00e9grit\u00e9, Kess pr\u00e9voit de recr\u00e9er ses branches \u00e0 partir de patches individuels. Comme cause la plus probable du changement d'auteur, Kess suspecte une tentative infructueuse de restauration du d\u00e9p\u00f4t apr\u00e8s sa corruption. <\/p>\n
Linus n'\u00e9tait pas satisfait de cette explication, car selon lui, les modifications de l'historique des commits dans le d\u00e9p\u00f4t de Kess ressemblent beaucoup \u00e0 des actions d\u00e9lib\u00e9r\u00e9es, plut\u00f4t qu'\u00e0 une d\u00e9faillance accidentelle. Le rebasage de l'historique des modifications via l'op\u00e9ration \u00ab git rebase \u00bb pourrait expliquer la r\u00e9\u00e9criture de l'auteur du commit, mais Linus ne peut pas comprendre comment une telle op\u00e9ration \u00ab git rebase \u00bb aurait pu \u00eatre effectu\u00e9e par erreur. <\/p>\n
La r\u00e9\u00e9criture d'un ou deux commits aurait encore pu \u00eatre consid\u00e9r\u00e9e comme une erreur, mais plus de six mille commits de fusion ont \u00e9t\u00e9 r\u00e9\u00e9crits dans le d\u00e9p\u00f4t de Kess, dont 330 avaient Linus comme auteur, alors que ces commits n'\u00e9taient pas issus de l'arbre git de Linus. Les modifications effectu\u00e9es ressemblent davantage au travail d'un script qu'\u00e0 un r\u00e9sultat de corruption d'informations sur le support, car elles n\u00e9cessitent la recr\u00e9ation s\u00e9par\u00e9e de chaque commit. <\/p>\n
Kes a assur\u00e9 Linus qu'il n'avait pas fait cela intentionnellement et qu'il ne m\u00e8nerait jamais de telles exp\u00e9riences sans pr\u00e9venir (par exemple, la derni\u00e8re exp\u00e9rience sur l'appel des collisions de commits avait \u00e9t\u00e9 convenue avec Linus). Cette semaine, il a effectu\u00e9 plusieurs op\u00e9rations manuelles sur le d\u00e9p\u00f4t et tentera maintenant de comprendre ce qui a mal tourn\u00e9 et de reproduire le probl\u00e8me. Par exemple, Kes a ex\u00e9cut\u00e9 une op\u00e9ration de rebase sur les arbres git for-next\/hardening et for-linus\/hardening, en utilisant, contrairement aux pr\u00e9c\u00e9dentes transformations similaires, la branche \u00ab master \u00bb, plut\u00f4t que rc2. Au cours de cette op\u00e9ration, il a apport\u00e9 des modifications aux scripts pour v\u00e9rifier les demandes de fusion. <\/p>\n