Linus Torvalds ordonne le blocage de Kees Cook après avoir détecté des altérations suspectes 

Linus Torvalds dans un Con

Il y a quelques jours , un incident inhabituel s'est produit et a secoué la communauté du noyau Linux : Linus Torvalds a ordonné le blocage immédiat du compte de Kees Cook sur kernel.org après avoir détecté des modifications dans le dépôt Git de ce développeur.

Kees Cook, reconnu pour son leadership au sein de l'équipe de sécurité d'Ubuntu et pour la maintenance de plus d'une douzaine de sous-systèmes liés à la sécurité du noyau, a été temporairement interdit de soumettre des modifications le temps que les faits soient clarifiés.

Modification de la paternité et des signatures dans le référentiel Kees Cook

Le problème est survenu suite à une demande d'intégration de modifications dans la branche du noyau 6.16. Linus a identifié des références à un dépôt contenant des commits manipulés où son nom figurait comme auteur et confirmateur, alors qu'il ne les avait pas effectués. L'un des exemples les plus graves était l'existence d'un commit dupliqué, identique à l'original mais avec un hachage SHA1 différent, qui incluait faussement la signature de Linus Torvalds.

Ces modifications ne pouvaient pas être attribuées simplement à une erreur accidentelle lors d'une opération de rebase git, car elles impliquaient la modification massive d'informations sensibles, notamment plus de 6 000 commits réécrits, dont 330 portaient le nom de Linus comme auteur.

Réaction de Torvalds : soupçons de manipulation délibérée

Linus Torvalds n'a pas caché son inquiétude et a décrit les événements comme potentiellement malveillants :

« Une ou deux réécritures pourraient être une erreur. Mais des milliers d'entre elles, dont beaucoup portent ma fausse signature, ne le sont pas », a-t-il déclaré.

Compte tenu de l'ampleur des changements et du risque pour l'intégrité de l'arbre du noyau officiel, Torvalds a demandé à Konstantin Ryabitsev, administrateur de l'infrastructure kernel.org, de bloquer l'accès de Kees Cook jusqu'à ce que la situation soit clarifiée.

En réponse, Kees Cook a expliqué avoir récemment rencontré des problèmes techniques susceptibles d'avoir déclenché l'incident. Il a indiqué que son SSD avait dysfonctionné lors d'opérations de copie, ce qui avait entraîné la corruption de plusieurs dépôts. Suite à ces erreurs, il a tenté de restaurer l'état de son dépôt à l'aide de `git rebase` et de divers outils d'automatisation.

Cependant, ces opérations ont été effectuées sur des branches critiques , telles que for-next/hardening et for-linus/hardening, ce qui a entraîné une modification accidentelle de l'historique du dépôt, notamment des changements dans la paternité des commits. Malgré ses explications, Linus est resté sceptique.

« Je ne comprends pas comment un dépassement accidentel a pu se produire, encore moins avec ce volume de modifications. »

Le vrai coupable : git-filter-repo et les bandes-annonces b4

Dans un message ultérieur, Kees Cook a identifié la source probable de l'erreur : l'utilisation combinée de deux outils, git-filter-repo et b4 trailers, qui manipulent l'historique des commits et les trailers (étiquettes telles que Signed-off-by :) dans les commits.

Cette utilisation abusive des utilitaires aurait entraîné la réécriture automatique de milliers de commits , notamment le remplacement de l'auteur par la valeur par défaut (ici, Linus Torvalds), sans que Kees ne s'en aperçoive sur le moment . Konstantin Ryabitsev, auteur de l'outil b4, a confirmé cette hypothèse et affirmé que Cook n'avait aucune intention malveillante. En réalité, le système générait déjà des avertissements qui avaient été ignorés.

Une fois la situation clarifiée, l'accès de Kees Cook à kernel.org a été rétabli. Par mesure de précaution, il a été annoncé que l' outil b4 intégrera un nouveau contrôle de sécurité empêchant la modification des commits dont l'auteur ne correspond pas à l'identité de l'utilisateur actuel. L'objectif est d'éviter des erreurs similaires et de protéger l'intégrité du code source du noyau.

Kees, quant à lui, s'est engagé à recréer les branches concernées à partir de correctifs individuels et à analyser en détail les étapes ayant conduit à l'erreur. Bien que cet incident ait tendu les relations au sein de l' équipe de développement du noyau, il a également mis en lumière l'importance d'utiliser les outils de réécriture de l'historique avec prudence, notamment dans des projets aussi critiques que le noyau Linux.

Enfin, il convient de mentionner que cet incident entre Linus Torvalds et Kees Cook sert d'avertissement quant aux dangers de la manipulation de l'historique des commits, et que grâce à l'intervention rapide de l'équipe de kernel.org et à la transparence du processus, la situation a été maîtrisée.

Enfin, si vous souhaitez en savoir plus, vous trouverez les détails en suivant ce lien.


Ajouter comme source préférée dans Google