TECNOLOGíA, INTERNET, JUEGOS
425 meneos
5399 clics
Debian se lo quiere poner difícil a la CIA con las ‘compilaciones reproducibles’

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.

| etiquetas: debian , cia , compilaciones reproducibles , código abierto , linux
174 251 0 K 478
174 251 0 K 478
en un pais que los troyanos estan autorizados por ley como es españa, es una excelente noticia para todos los usuarios de debian, para el resto, siempre se sentirán mas acompañados en sus ordenadores.
Debian dando ejemplo. Para que haya un avance siempre debe existir un referente.
Linux es ETA
#24 No. O sea, tu puedes bajarte el deb-src y comprobar el checksum, puedes bajarte el deb y comprobar el checksum, pero cuando compilas el deb-src para sacar el ejecutable que también te viene en el .deb, puede que te salgan checksum distinto por una serie muy larga de factores que el proyecto de "compilación reproducible" quiere arreglar
‘compilaciones reproducibles’

Eso lo tiene GUIXSD, pero claro, como es para frikis hardcore...
#1 Vaya, ya me has hodido el status!!

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…   » ver todo el comentario
#13 No es eso, es que es bastante densa. Usa a Guile (Un Scheme) como base para GUIX y la API de los demonios y configuración del sistema.

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 :-D
#14 Con eso ya tengo la carpeta de fuera en Linux dentro del Plan9 de QEMU gracias a usar Drawterm 

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 :-D

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.
#18
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
#19 Oh!! Gracias por la información.
#1 En los manuales y las ayudas de GUIXSD usan términos como "likely" ("probablemente") y "helps maximize build reproducibility" ("ayuda a maximizar que sean compilaciones reproducibles"). Todo apunta a que "lo intentan" pero si se consigue o no depende varios factores, no es un sistema que asegure un binario idéntico bit a bit.

Algo que no veo que haga el GUIXSD a la hora de compilar es emular un procesador virtual. Y es que los procesadores…   » ver todo el comentario
#28 GUIX tiene el comando "guix environment" y también "guix vm".

"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.
#29 Por lo general compilan paquetes para i586 o i686 amd64 al mínimo común en entre ellos.

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…   » ver todo el comentario
#10 GUIXSD es la distro creada en torno a GUIX, aunque puedes meter GUIX en Debian o Fedora sin problema.

Uso paquetes de GUIX para tener el MESA más reciente para compilar emuladores, y con GCC5 para usarlo de pruebas con XQemu.
¿A la CIA, no sería más bien a la NSA?
#16 A eso mismo me refiero: tú coges el fuente del que Debian asegura que ha generado sus paquetes binarios, lo compilas, comparas el hash de lo que tú has compilado con lo que distribuye Debian, y si coincide, puedes certificar que los paquetes binarios de Debian no han sido alterados. Y si, además, compruebas las fuentes a ver si hay puertas traseras, puedes certificar que, efectivamente, Debian no incorpora puertas traseras que hayas podido detectar.

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.
#20 ¿antes no era así?
La peña que habló de esto en el Fosdem parecían salidos de la peli de "Hackers", vaya personajes.

archive.fosdem.org/2015/schedule/event/stretching_out_for_trustworthy_

Faltaba Angelina Jolie, por supuesto.
#6 Joder con las pintas de la peña. Y pensar que si los ves por la calle eres capaz de cambiar de acera y luego resulta que son unos genios.
¿No publican los checksum con las imágenes para comprobar que precisamente no se ha alterado el fichero?
#8 No basta con eso: la idea es que puedes compilar las fuentes y comparar el binario que has producido con el que viene en la distribución. Si coincide, puedes certificar a terceros que las fuentes de las que proviene ese binario no han sido alteradas respecto a las fuentes originales.
#11 pero binarios distintos no dan checksums distintos? O: Si se altera el fuente no se altera el checksum?
#11 Bueno, realmente la garantía es un poco más débil. Siempre puede ocurrir que el compilador que usas (y el que se usó para compilarlo) inyecte código malintencionado durante el proceso de compilación.
#26 Cierto, conocía eso. Sin embargo, no veo forma de garantizar que tu compilador está libre de ese tipo de puertas traseras... ¿y tu?
#32 No, es que no la hay. Aunque construyeras desde cero los circuitos de tu propio ordenador, siempre te quedaría la duda de si, una noche mientras dormías, la NSA ha modificado alguna parte de tu sistema :roll:.

Más información: c2.com/cgi/wiki?TheKenThompsonHack [ENG]
#35 Eso era antes. Ahora hay más de un compilador y enlazador.
#8 Los checksums no te garantizan que el código binario se generó a partir de las fuentes originales. Ahora tu podrás compilar el código original y ver si realmente el binario que se te genera es el mismo (el cual, si no se toman esfuerzos adicionales, depende del entorno de compilación). Es un pasito adicional para que tengas que confiar menos en la buena fe de los distribuidores de binarios.
No termino de entender a lo que se refiere el artículo. No podías ya desde siempre bajar el src de cada paquete y compilarlo tu mismo?
#7 Es diferente. Con las compilaciones reproducibles el paquete siempre sale respecto u unas normas y de ahí no sale.

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.
#9 GUIX no era un gestor de paquetes? o me estoy perdiendo alguna distro?

en.wikipedia.org/wiki/GNU_Guix
#7 si, eso se podia hacer, los reproducible builds son un intento por reproducit bit a bit el resultado de una compilación, da lo mismo si en tu ordenador o en el de mi prima.

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…   » ver todo el comentario
#15 "El objetivo no es solo prevenir inyeccion de binarios en las maquinas de compilación, si no garantizar compilaciones cruzadas,"

A ver para cuando algo similar a plan9.

objtype=arm mk. Desde intel. Ya. Hecho. De serie. Sin hacks astronómicos.
Me pregunto lo mismo que #7, añadiendo, y Gentoo pasa lo mismo???
El paso del tiempo demuestra que la forma de hacer las cosas de debian siempre es la correcta, y que Stallman tiene razón.
#31 Nadie es perfecto, pero si, Stallman y Debian suelen acertar bastante.

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.
¿Linuxeame?

Enviado desde Debian
comentarios cerrados

menéame