Linus Torvalds bloquea a Kees Cook tras detectar commits alterados en el kernel de Linux: Todo lo que se sabe

Un inusual incidente en el desarrollo del kernel de Linux ha sacudido a la comunidad de código abierto. Linus Torvalds, creador y principal mantenedor del kernel, ordenó el bloqueo temporal del reconocido desarrollador Kees Cook tras descubrir más de 330 commits falsificados con su nombre como autor en un repositorio Git.

Los hechos, calificados inicialmente por Torvalds como "potencialmente maliciosos", derivaron en una investigación técnica que reveló un error en herramientas de automatización y fallos de hardware.

¿Qué ocurrió?

Detección de commits alterados

El 31 de mayo, Torvalds revisó una solicitud de incorporación de cambios (pull request) de Cook para la versión 6.16 del kernel. Allí identificó:

• Commits duplicados: Un commit legítimo de Torvalds (SHA1: 9d230d500b0e) aparecía replicado con un hash distinto (f8b59a0f90a2) y firmado falsamente como suyo.

• Reescritura masiva: Más de 6,000 commits modificados, 330 con autoría falsa de Linus.

Torvalds reaccionó con dureza:

"Una o dos reescrituras podrían ser un error. Pero miles de ellas, muchas con mi firma falsificada, no lo son".

Bloqueo inmediato

Ante la sospecha de manipulación deliberada, Torvalds solicitó a Konstantin Ryabitsev (administrador de kernel.org) deshabilitar el acceso de Cook hasta aclarar el incidente.

La explicación de Kees Cook

Cook, líder de seguridad en Ubuntu y mantenedor de subsistemas críticos del kernel, atribuyó el problema a:

1. Fallo en un SSD: Corrupción de datos durante operaciones de copia, que dañó sus repositorios locales.

2. Uso accidental de herramientas: Combinó git-filter-repo (reescritura de historial) y b4 trailers (gestión de metadatos), lo que alteró autorías y firmas.

3. Rebase manual defectuoso: Intentó reconstruir ramas como for-next/hardening sobre una base incorrecta (master en lugar de rc2).

Cook aseguró que no hubo intención maliciosa y se comprometió a reconstruir las ramas desde parches limpios.

Investigación y resolución

• Konstantin Ryabitsev confirmó que el error se originó en b4 trailers, que reescribió metadatos sin validar autorías.

• Medidas correctivas:

  • Se añadieron validaciones en b4 para evitar modificaciones de commits ajenos.

  • Cook recuperó su acceso tras demostrar la naturaleza accidental del incidente.

Implicaciones y reacciones

1. Seguridad en código abierto: El caso destaca los riesgos de herramientas que manipulan historiales Git, incluso en manos de expertos.

2. Escepticismo inicial de Torvalds: Cuestionó cómo un rebase podría falsificar miles de commits "por error".

3. Transparencia comunitaria: La rápida publicación de los hilos de discusión en lkml.org reforzó la confianza en el proceso.

Lecciones aprendidas

• Verificación rigurosa: Se reforzarán los checks automatizados para commits en kernel.org.

• Copia de seguridad: Fallos de hardware pueden comprometer repositorios críticos.

• Comunicación clara: Cook evitó una crisis mayor al explicar técnicamente el error.

¿Qué sigue?

• Cook reenviará sus parches para hardening una vez reconstruidos.

• El equipo de kernel.org revisará políticas de uso de git-filter-repo.

Este incidente, aunque resuelto, subraya la fragilidad de los sistemas colaborativos y la importancia de la vigilancia en proyectos globales como Linux.