425 meneos
5399 clics
Debian se lo quiere poner difícil a la CIA con las ‘compilaciones reproducibles’
El código abierto garantiza por encima de cualquier otro modelo de desarrollo que el software es lo que dice ser y nada más, que no esconde puertas traseras y que cada vulnerabilidad hallada es en efecto un error de programación, no un agujero dejado ex profeso. Sin embargo, tiene un hándicap para el usuario final, y es que este tiene difícil comprobar su autenticidad.
|
comentarios cerrados
Eso lo tiene GUIXSD, pero claro, como es para frikis hardcore...
archive.fosdem.org/2015/schedule/event/stretching_out_for_trustworthy_
Faltaba Angelina Jolie, por supuesto.
En distros como GUIX esto ocurre de facto y cada paquete se compila respecto a unas reglas muy estrictas. Es casi imposible de troyanizar, y encima usa Linux-libre.
en.wikipedia.org/wiki/GNU_Guix
Uso paquetes de GUIX para tener el MESA más reciente para compilar emuladores, y con GCC5 para usarlo de pruebas con XQemu.
Sí desde 2005 varios amigos y conocidos me vienen llamando friki, nerd y otras lindezas porque no adopté de inmediato la distribución que Canonical había hecho (y lanzado con gran estruendo) y me empeñaba en seguir con mi Slackware.
Ahora sigo usando Slackware en la intimidad (aunque para conectarme a Internet suelo hacerlo con un portátil que corre FreeBSD y NetBSD) pero para las clases de GNU/Linux suelo usar una Mint (por aquello de contentar a la gente y explicarles las cosas usando la distribución que usa la mayoría de "mis alumnos").
Cuando algunos quieren profundizar un poco más (por lo general, gracias a este tipo de noticias) y hay que mostrarles como se compilan los "paquetes"; arranco la Slackware porque me resulta más cómodo (además de tener ya todas la herramientas para compilar), y porque con los SlackBuilds siempre resulta menos complicado (para empezar a compilar paquetes). En ese momento vuelvo a ser el friki.
Pero es la primera vez que leo lo de GUIXSD. Así que no soy lo bastante friki??
Un poco la antítesis de NetBSD.
Tambien tengo 9front en virtual la cual me conecto desde Drawterm. El C de Plan9 me encanta, se aprende muy facil y los namespaces son DIOS.
bind -a /mnt/term/home/ander/Escritorio/cosas $home/cosas
Con eso ya tengo la carpeta de fuera en Linux dentro del Plan9 de QEMU gracias a usar Drawterm
El objetivo no es solo prevenir inyeccion de binarios en las maquinas de compilación, si no garantizar compilaciones cruzadas, poder compilar en una arquitectura y que salga identico bit a bit. Es una idea que surguio en debian pero ahora mismo es proyecto de la fundación linux y esta siendo adoptado pòr practicamente todas las distros. La compilación verificable "graba" el entorno de compilacón para poder reproducirlo en cualquier momento y lugar.
Entre las cosas curiosas que se han hecho, esta cambiar los "timestamps" antes se grababa la fecha de compilación lo que hacia a los binarios diferentes. Se ha cambiado la manera de manejar los "tar" para asegurar que se extraen en el mismo orden, resulta que si se compila y enlaza en un orden distinto no da un binario exactamente igual y cosas asi. Me ha resultado de lo mas interesante.
web
reproducible.debian.net
blog de uno de los que esta revolviendo el tema
people.debian.org/~lunar/blog/
Por cierto el titular "se lo pone dificil a la cia" es para darle de tortas a quien lo haya hecho, de ponerselo dificil a alguien es a la NSA, mucha peli de alucinados mucha tonteria con la cia, mucho titular con gancho y de informarse nada.
A ver para cuando algo similar a plan9.
objtype=arm mk. Desde intel. Ya. Hecho. De serie. Sin hacks astronómicos.
Por todos los dioses!!
Vale, reconozco que lo mío no es paranoia y que eso de cerrar la sesión en Slackware para arrancar otra con FreeBSD para conectarme a Internet, es como calentar yogures en el microondas para quitarle el frío del frigorífico
Siempre he querido meterme a probar eso de Plan9 y siempre me ha dado pereza empezar y no encontrar después suficiente información (o ayuda).
Ya decía yo que uno que fue medio hipy no puede ser friki tantos años después
Creo que me hacía ilusión, más porque friki suena "joven" que porque en realidad yo me considerase como tal.
Eso si, raro si que soy.
9front.org/ para bajarte la ISO
fqa.9front.org/ FAQ con el uso.
Lo que vas a ver al iniciar el sistema.
www.quanstro.net/newbie-guide.pdf
Si quieres programar en C. No te asustes, es mucho más simple de lo que crees.
lsub.org/who/nemo/9.intro.pdf
Si las fuentes que usas tú y las que uso Debian son las mismas, los binarios deberían ser iguales. Si hay algún cambio (una puerta trasera añadida a los binarios pero no a las fuentes) no coincidirán.
Algo que no veo que haga el GUIXSD a la hora de compilar es emular un procesador virtual. Y es que los procesadores tratan datos de forma distinta, un caso muy conocido es el de la coma flotante, lo cual genera pequeñas desviaciones que terminan en un binario distinto al que puedas compilar en otro procesador distinto.
En el caso de Debian no sé como tienen previsto hacerlo, en el caso de Bitcoin se usan máquinas virtuales qemu que emulan, entre otros, un procesador y por lo tanto el binario es idéntico se haga en un equipo u otro, e incluso se haga en una arquitectura u otra (x86, x64, ppc, arm, etc.).
gnu.org/software/guix/manual/html_node/Features.html#Features
gnu.org/software/guix/manual/html_node/Invoking-guix_002ddaemon.html#i
news.ycombinator.com/item?id=9747688
"lo cual genera pequeñas desviaciones que terminan en un binario distinto al que puedas compilar en otro procesador distinto."
Por lo general compilan paquetes para i586 o i686 amd64 al mínimo común en entre ellos.
Tienes opciones que generan un binario idéntico.
Y usar Qemu es contraproducente, te llevas los bugs de la máquina virtual a casa. Otra cosa es la compilación cruzada.
Quizá no me he explicado. Lo que hace que el binario sea distinto es el procesador en el cual compilas, no el subset de instrucciones para el que se compila.
Un usuario que compile en un procesador Amd y uno en Intel obtendrán binarios distintos debido a que internamente los procesadores hacen algunos cálculos de forma distinta con resultados distintos, especialmente en el ámbito de la coma flotante.
Crear un entorno de usuario "similiar", cuasi "idéntico", o incluso "idéntico" en el ámbito del sistema operativo no te asegura que dos binarios sean bit a bit iguales. Necesitas usar el mismo hardware para asegurarte, y la forma más barata y eficaz es que ese hardware sea virtual.
Tienes opciones que generan un binario idéntico.
¿Siempre? ¿O quizá algunas veces no?
Y usar Qemu es contraproducente, te llevas los bugs de la máquina virtual a casa.
El objetivo es que el binario sea idéntico. Si es idéntico tendrá los mismos errores en todas las plataformas, lo que facilita su corrección.
Por otro lado para el ejemplo de Bitcoin es bueno llevarse todos los mismos bugs, ya que es de los pocos sistemas donde es más importante que funcione "igual de mal" en todos sitios a que en algunos funcione bien y en otros mal.
Por ejemplo, la GPLv2 obliga a incluir los scripts usados para la compilación e instalación del binario, y cualquier otro requisito necesario para generar, instalar, permitir modificar y hacer funcionar las modificaciones.
Debian ahora lo va a hacer con todos los paquetes y bien, independientemente de la licencia. Un paso necesario e importantísimo para la seguridad.
Enviado desde Debian
Más información: c2.com/cgi/wiki?TheKenThompsonHack [ENG]