{"id":125748,"date":"2025-06-01T15:05:12","date_gmt":"2025-06-01T13:05:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka"},"modified":"2025-06-01T15:05:12","modified_gmt":"2025-06-01T13:05:12","slug":"inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","title":{"rendered":"Incidente de sustituci\u00f3n de commits en la rama del n\u00facleo de Linux por Kesa Cook","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds exigi\u00f3 al administrador de kernel.org que bloqueara inmediatamente la cuenta de Kesa Cook, el exjefe de sistemas de kernel.org y l\u00edder del equipo de seguridad de Ubuntu, quien supervisa 14 subsistemas relacionados con la seguridad en el n\u00facleo. Konstantin Ryabtsev, responsable de la infraestructura de kernel.org, ejecut\u00f3 el bloqueo. El motivo del bloqueo fue una solicitud de 'pull' para incluir en la rama del n\u00facleo 6.16 cambios que hac\u00edan referencia a un repositorio git donde se hab\u00eda alterado la informaci\u00f3n sobre la autor\u00eda de algunos commits. <\/p>\n
En el repositorio de git soportado por Kesa, hubo cambios ficticios en el campo del autor y del committer que indicaban a \u00abLinus Torvalds\u00bb, pero Linus no los hab\u00eda a\u00f1adido. Por ejemplo, bajo el nombre de Linus, en la rama de Kesa, hab\u00eda un commit que repet\u00eda otro commit en la rama de Linus, pero con un hash SHA1 diferente. Ambos commits parecen id\u00e9nticos, salvo por la informaci\u00f3n de la firma. <\/p>\n
Los cambios no parec\u00edan un error accidental al ejecutar la operaci\u00f3n \u00abgit rebase\u00bb, ya que conten\u00edan informaci\u00f3n incorrecta sobre el autor del commit. Linus Torvalds consider\u00f3 esto como indicios de una posible actividad maliciosa y decidi\u00f3 bloquear la recepci\u00f3n de cualquier cambio de Kesa hasta esclarecer las causas de tales manipulaciones y confirmar que el sistema de Kesa no hab\u00eda sido comprometido. <\/p>\n
Kesa respondi\u00f3 que no entiende c\u00f3mo pudo suceder tal cosa. Antes, hab\u00eda tenido problemas al intentar fusionar varias de sus ramas de git, despu\u00e9s de lo cual intent\u00f3 resolverlos con la operaci\u00f3n \u00abgit rebase\u00bb, pero parece que eso no ayud\u00f3. Todo esto ocurri\u00f3 en medio de fallos en el SSD, que presentaba errores durante la copia. Kesa pensaba que despu\u00e9s del fallo hab\u00eda logrado restaurar el estado de sus repositorios, pero al parecer no fue as\u00ed. Para recuperar la integridad, Kesa tiene la intenci\u00f3n de recrear sus ramas a partir de parches individuales. Considera que la causa m\u00e1s probable del suplantaci\u00f3n del autor fue un intento fallido de restaurar el repositorio tras su da\u00f1o. <\/p>\n
A Linus no le conven\u00eda esta explicaci\u00f3n, ya que, en su opini\u00f3n, los cambios en la historia de commits en el repositorio de Kesa se asemejan m\u00e1s a acciones intencionadas que a un fallo accidental. El rebase de la historia de cambios mediante la operaci\u00f3n \u00abgit rebase\u00bb podr\u00eda explicar la sobrescritura del committer, pero Linus no puede entender c\u00f3mo tal operaci\u00f3n \u00abgit rebase\u00bb pudo ser realizada por error. <\/p>\n
La reescritura de uno o dos commits podr\u00eda atribuirse a un error, pero en el repositorio de Kess se han reescrito m\u00e1s de seis mil commits de fusi\u00f3n, de los cuales 330 fueron atribuidos a Linus, aunque esos commits no provinieron del \u00e1rbol git de Linus. Los cambios realizados se parecen m\u00e1s al trabajo de un script que al resultado de una corrupci\u00f3n de datos en el almacenamiento, ya que requieren la recreaci\u00f3n separada de una copia de cada commit. <\/p>\n
Kes le asegur\u00f3 a Linus que no lo hizo intencionadamente y no llevar\u00eda a cabo experimentos similares sin previo aviso (por ejemplo, el experimento anterior para provocar colisiones de commits fue acordado con Linus). Esta semana realiz\u00f3 varias operaciones manuales en el repositorio y ahora intentar\u00e1 descubrir qu\u00e9 sali\u00f3 mal y reproducir el problema. Por ejemplo, Kes ejecut\u00f3 la operaci\u00f3n rebase para los \u00e1rboles de git for-next\/hardening y for-linus\/hardening, utilizando a diferencia de transformaciones anteriores la rama \u00abmaster\u00bb, en lugar de rc2. Durante esta operaci\u00f3n, realiz\u00f3 cambios en los scripts para verificar las solicitudes de push. <\/p>\n
Nota adicional: Kes Cook public\u00f3 otro mensaje, en el que afirm\u00f3 que, probablemente, el problema surgi\u00f3 debido al uso de la herramienta \u00abgit-filter-repo\u00bb, que realiza la reescritura de la historia de commits en el repositorio, junto con el comando \u00abb4 trailers\u00bb, destinado a obtener y aplicar trailers a los commits (por ejemplo, \u00abSigned-off-by:\u00bb). \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"