Linus Torvalds exigió al administrador de kernel.org que bloqueara inmediatamente la cuenta de Kesa Cook, el exjefe de sistemas de kernel.org y líder del equipo de seguridad de Ubuntu, quien supervisa 14 subsistemas relacionados con la seguridad en el núcleo. Konstantin Ryabtsev, responsable de la infraestructura de kernel.org, ejecutó el bloqueo. El motivo del bloqueo fue una solicitud de 'pull' para incluir en la rama del núcleo 6.16 cambios que hacían referencia a un repositorio git donde se había alterado la información sobre la autoría de algunos commits.
En el repositorio git mantenido por Kesa había cambios falsos, en los campos de autor y committer se especificaba 'Linus Torvalds', pero Linus no los había añadido. Por ejemplo, con el nombre de Linus en la rama de Kesa existía un commit que duplicaba otro commit en la rama de Linus, pero con un hash SHA1 diferente. Ambos commits se ven idénticos, excepto por la información de la firma.
Los cambios no parecían un error accidental durante una operación de 'git rebase', ya que contenían información incorrecta sobre el autor del commit. Linus Torvalds consideró esto como señales de una posible actividad maliciosa e inició el bloqueo de cualquier cambio de Kesa, hasta aclarar las razones de tales manipulación y confirmar que el sistema de Kesa no había sido comprometido.
Kesa respondió que no entiende cómo pudo suceder algo así. Antes había encontrado problemas al intentar fusionar varias de sus ramas git, tras lo cual intentó resolverlo con una operación de 'git rebase', pero parece que no ayudó. Todo esto ocurrió en medio de un fallo en el disco SSD, que arrojaba errores durante la copia. Kesa creía que tras el fallo había logrado restaurar el estado de sus repositorios, pero evidentemente no es así. Para restaurar la integridad, Kesa tiene la intención de recrear sus ramas a partir de parches individuales. Como la razón más probable del cambio de autor, Kesa considera un intento fallido de restaurar el repositorio tras su corrupción.
A Linus no le convenció esa explicación, ya que, a su juicio, los cambios en el historial de commits en el repositorio de Kess son muy parecidos a acciones intencionadas, y no a un fallo casual. El rebase del historial de cambios mediante la operación «git rebase» podría haber explicado la reescritura del autor del commit, pero Linus no puede entender cómo se pudo cometer un error así con una operación «git rebase».
La reescritura de uno o dos commits podría atribuirse a un error, pero en el repositorio de Kess se han reescrito más de seis mil commits de fusión, de los cuales 330 fueron atribuidos a Linus, aunque esos commits no provinieron del árbol git de Linus. Los cambios realizados se parecen más al trabajo de un script que al resultado de una corrupción de datos en el almacenamiento, ya que requieren la recreación separada de una copia de cada commit.
Kess aseguró a Linus que no lo había hecho a propósito y que no llevaría a cabo experimentos así sin previo aviso (por ejemplo, el experimento anterior sobre colisiones de commits fue acordado con Linus). Esta semana realizó varias operaciones manuales en el repositorio y ahora intentará averiguar qué salió mal y reproducir el problema. Por ejemplo, Kess realizó una operación de rebase para los árboles git for-next/hardening y for-linus/hardening, utilizando, a diferencia de transformaciones similares anteriores, la rama «master», en lugar de rc2. Durante esta operación, modificó los scripts para verificar las solicitudes de push.
Adición: Kess Cook publicó otro mensaje, afirmando que lo más probable es que el problema surgiera del uso de la utilidad «git-filter-repo», que realiza la reescritura del historial de commits en el repositorio, combinada con el comando «b4 trailers», destinado a obtener y aplicar trailers a los commits (por ejemplo, «Signed-off-by:».
Fuente: opennet.ru
