Greg Kroah-Hartman prohibió a la Universidad de Minnesota contribuir al kernel de Linux e hizo un gran esfuerzo para restaurar y reevaluar 190 parches que provenían de la misma universidad. ¿Es una reacción exagerada o es la única respuesta posible?
La ironía de esta situación es que el controvertido proyecto que provocó la pérdida de confianza en la Universidad de Minnesota tenía como objetivo mejorar la seguridad de Linux. La investigación, realizada en agosto de 2020, fue dirigida por Kangije Lu, profesor asistente y estudiante de posgrado Qjushi Wu, y su artículo «Sobre la viabilidad de la introducción sigilosa de vulnerabilidades en software de código abierto a través de compromisos hipócritas» fue aceptado para el 42 ° Simposio IEEE sobre seguridad. y Privacidad. La investigación, que fue apoyada por la NSF (National Science Foundation), incluyó garantías explícitas para garantizar que no se fusionaran errores en el kernel de Linux como resultado del experimento, aunque ahora parece que muchos errores de cierre de mutex se han deslizado. un error que ha sido corregido.
Sin embargo, la prohibición no se emitió en respuesta a este documento. En cambio, el detonante fue una serie más reciente de «parches obviamente malos» presentados por Aditya Pakki, otra de los estudiantes graduados de Lu, quien explicó que fueron enviados como resultado de su trabajo en «un nuevo analizador estático».
Para Kroah-Hartmann, quien como principal mantenedor del kernel de Linux, tiene la responsabilidad final de su seguridad, enviar nuevos parches con errores fue la gota que colmó el vaso y su sospecha era que una vez más era parte de algún experimento de investigación, como se refleja en su tweet :
El enlace en el tweet va a una respuesta por correo electrónico a Aditya Pakki en la que Hartmann escribe:
Usted y su equipo han admitido públicamente que han parcheado errores conocidos para ver cómo reaccionaría la comunidad del kernel y han publicado un documento basado en ese trabajo.
Ahora envía un nuevo lote de parches obviamente incorrectos nuevamente, entonces, ¿qué debería pensar en tal cosa?
Obviamente, NO fueron creados por una herramienta de análisis estático de ninguna inteligencia, ya que todos son el resultado de patrones completamente diferentes y, obviamente, todos ni siquiera resuelven nada. Entonces, ¿qué se supone que debo estar pensando aquí, aparte del hecho de que usted y su equipo siguen experimentando con los desarrolladores de la comunidad del kernel mediante la publicación de estos parches sin sentido? …
A nuestra comunidad no le gusta que lo prueben y envíen notas de parche que no hacen nada a propósito o introducen errores a propósito. Si desea trabajar de esta manera, le sugiero que busque una comunidad diferente para ejecutar sus experimentos, no es bienvenido aquí.
Por esta razón, ahora tendré que prohibir todas las contribuciones futuras de su Universidad y arrebatarme sus contribuciones anteriores, ya que obviamente fueron presentadas de mala fe con la intención de causar problemas.
Cuando se le preguntó sobre su opinión Linus Torvalds, dio una respuesta muy suave:
«No creo que haya sido un gran problema desde un punto de vista técnico, pero la gente está cabreada y obviamente es un abuso de confianza».
En un intento por levantar la prohibición, ayer se hizo una disculpa como «Carta abierta a la comunidad de Linux y firmada por Kangjie Lu, Qiushi Wu y Aditya Pakki, de la Universidad de Minnesota. Incluye la declaración:
Solo queremos que sepa que nunca dañaremos intencionalmente a la comunidad del kernel de Linux y que nunca presentaremos vulnerabilidades de seguridad. Nuestro trabajo se ha realizado con las mejores intenciones y es encontrar y corregir vulnerabilidades de seguridad.
Más tarde declara:
Somos un grupo de investigación cuyos miembros dedican sus carreras a mejorar el kernel de Linux. Durante los últimos cinco años, hemos estado trabajando para encontrar y corregir vulnerabilidades de Linux. Las observaciones pasadas con el proceso de parche nos habían motivado a investigar y abordar problemas con el proceso de parche también.
Reconociendo la ira que la comunidad de Linux sentía hacia ellos, dicen:
Nos disculpamos incondicionalmente por lo que ahora reconocemos como una violación de la confianza compartida en la comunidad de código abierto y pedimos perdón por nuestros errores.
Pero no es tan simple. La confianza se rompió y la acción de este equipo de investigación contaminó no solo a los tres firmantes de la carta abierta, sino a toda la Universidad de Minnesota. La respuesta de Hartman a estas disculpas fue un simple «Gracias» y se refiere a una carta enviada por el Consejo Asesor Técnico de la Fundación Linux a la Universidad de Miinesota en la que se describe la acción específica requerida del grupo de investigación y la universidad. En su totalidad para recuperar el confianza de la comunidad del kernel de Linux.
Parece totalmente justificado que se necesiten más que palabras para reconstruir la confianza en esta situación, pero vayamos más allá. Esto nunca debió de haber pasado. Linux es un software de misión crítica en el que dependen las grandes corporaciones e incluso los proyectos de exploración de Marte; no debe verse como un entorno de investigación, por muy loables que sean los objetivos de investigación.
Más información
Respuesta a «Una carta abierta a la comunidad de Linus»
Sobre la viabilidad de introducir sigilosamente vulnerabilidades en el software de código abierto a través de Hypocrite Commits
Artículos relacionados
Financiamiento de Google para la seguridad de Linux
Tomando en serio la criticidad del código abierto
Colaboradores de código abierto: pago y otros motivos
La importancia de las contribuciones de código abierto
Qué atrae a los desarrolladores al código abierto
¿Por qué participar en el código abierto?
Para estar informado sobre nuevos artículos sobre TecnoPasion, suscríbase a nuestro boletín semanal, suscríbase al feed RSS y síganos en Gorjeo, Facebook o Linkedin.
Comentarios
Haga un comentario o vea los comentarios existentes usando Disqus
o envíe su comentario por correo electrónico a: [email protected]
