Matthew Garret – Ospherica

Hispalinux demanda a Microsoft en la UE, sus argumentos no convencen

La asociación española de usuarios de software libre Hispalinux ha presentado una demanda ante la Comisión Europea en la que alega que Microsoft dificulta la instalación de otros sistemas operativos y de software libre. Y la dificultad es, como todos ya sabréis, el sistema de arranque seguro, UEFI Secure Boot.

En Gizmodo se han puesto en contacto con el abogado de Hispalinux, José María Lancho, que ha confirmado que la demanda se ha presentado «porque Microsoft quiere proteger su monopolio con un nuevo obstáculo técnico en Windows 8«. La empresa de Redmond obliga a los fabricantes de PCs y portátiles con Windows 8 preinstalado a integrar el nuevo UEFI Secure Boot afirmando que dicha tecnología evita accesos no deseados a nuestros ordenadores, pero dicho sistema ha generado mucha polémica.

Sin embargo, varias distribuciones Linux han solucionado el problema. Algunas como Ubuntu, openSUSE, o Fedora anunciaron soporte para UEFI Secure Boot hace tiempo, y la propia Linux Foundation publicó hace semanas su propia solución para que cualquier distribución GNU/Linux pueda adoptarla.

¿Convencen los argumentos de Hispalinux? No demasiado, desde luego. Como explica Matthew Garret (desarrollador del soporte Secure Boot en la Linux Foundation), hay una diferencia clara entre Secure Boot y Restricted Boot:

Secure Boot es cualquier esquema de validación de arranque en el que el control en última instancia está en manos del propietario del dispositivo, mientras que Restricted Boot es cualquier esquema de validación de arranque en el que el control en última instancia está en manos de una tercera parte.

Así, lo que Microsoft hace necesario en dispositivos Windows 8 entra en la categoría de Secure Boot: si los fabricantes y OEMs cumplen lo que Microsoft requiere, el usuario debe ser capaz de desactivar Secure Boot completamente y también dejarlo habilitado, pero con su propia alternativa en cuanto a claves de confianza y binarios.

El propio Garret reconoce que «cualquier sistema que cumpla los requisitos de Microsoft es un sistema que respeta la libertad del propietario del ordenador para elegir cómo de restrictiva es su política de arranque«. De hecho, la Comisión Europea está al tanto de dichas disposiciones y en un anuncio oficial dejaron claro que aunque monitorizarán este y otros desarrollos del mercado, Microsoft parece haber cumplido las normas:

La Comisión no está actualmente en posesión de evidencias que sugieran que los requisitos de seguridad de Windows 8 resultan en la práctica ser una violación de las reglas de competitividad de la UE como se declara en los artículos 101 y 102 TFEU. En particular, en base a la información actualmente disponible para la Comisión, parece que los OEMs pueden decidir darle a los usuarios la opción de deshabilitar el UEFI Secure Boot.

Así es, desde luego, y eso parece dejar claro que la demanda de Hispalinux no llegará a ningún lado y en este caso, creo yo, es exagerada y llega al punto de ser un mero ataque FUD impropio de un organismo tan conocido como Hispalinux.

Linus Torvalds: «Esto no es un concurso de chupar p*****»

No hace falta desvelar lo que esconden los asteriscos, porque viniendo de Linus Torvalds estas declaraciones son ya algo habitual. El creador del kernel Linux no suele cortarse a la hora de expresar sus opiniones allá donde interviene, y en esta ocasión ha realizado un comentario tajante al entrar en una discusión sobre la forma de dar soporte a la tecnología Secure Boot.

Como señalan en Muktware, Uno de los desarrolladores de Red Hat le preguntó a Linus si podría incluir un parche para dar soporte a la tecnología Secure Boot:

«¿Puedes hacer un pull de este conjunto de parches, por favor?

Proporcionan la capacidad por la cual las claves se pueden añadir de forma dinámica a un kernel que esté funcionando en modo Secure Boot. Para permitir que se cargue una clave en tales condiciones, necesitamos que la clave esté firmada a su vez por otra clave que ya tenemos (y en la que confiamos), donde las claves que «ya tenemos» podrían incluir las que están embebidas en el kernel, las que están en la base de datos UEFI y las que están en el hardware criptográfico».

Pero Linus le contestó afirmando que el parche no podía ser incluido:

«No sin un montón de debate adicional. Francamente, esto es jodidamente estúpido. Todo esto parece estar diseñado sobre una serie de estúpidas interfaces por razones completamente tontas. ¿Por qué deberíamos hacer esto? Ni siquiera me gusta nuestro parser X.509. Y eso hace que las interfaces sean complicadas e idiotas, y ya han llegado a ser 11».

Matthew Garret, ex-empleado de Red Hat y autor del controlador universal de los PCs con UEFI Secure Boot, entró también a comentar:

«Solo hay una autoridad que firma esas claves, y solo firma binarios PE».

Lo que hizo que Linus explotara del todo (con razón, tal y como revelan en Muktware), ya que dejó claro lo que opinaba sobre este tema:

«Chicos, este no es un concurso de chupar p*****. Si quieres parsear binarios PE, adelante.

Si Red Hat quiere hacerle una m**** a Microsoft, es vuestro problema. No tiene nada que hacer con las tareas de mantenimiento del núcleo. Para vosotros es trivial tener una máquina que firme y haga el parsing del binario PE, verifique las firmas, y firme las claves resultantes con vuestra propia clave. Ya habéis escrito el código para ello, por dios bendito, es lo que hay en esa jodida petición de pull.

¿Por qué debería importarme? ¿Por qué debería el kernel ocuparse de esa estupidez del «Solo firmamos binarios PE»? Damos soporte a X.509, que es el estándar para las firmas digitales.

Haced esto en el espacio de usuario en una máquina en la que confiéis. No hay excusa para hacerlo en el kernel».

Otros desarrolladores veteranos como Theodore Ts’o (responsable de ext4) apoyaron a Linus en el debate, y dejaron claro que este tipo de parches no deberían aplicarse al kernel. Ahora queda por ver cuál es la decisión final, pero todo apunta a que los parches propuestos no formarán parte del núcleo Linux.