Portada
mis comunidades
otras secciones
#2:
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.
#15:
#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 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
https://reproducible.debian.net
blog de uno de los que esta revolviendo el tema
https://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.
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
https://reproducible.debian.net
blog de uno de los que esta revolviendo el tema
https://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.
#27:
#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
#13:
#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 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??
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??
Comentarios
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 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??
#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
#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
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
http://9front.org/ para bajarte la ISO
http://fqa.9front.org/ FAQ con el uso.
Lo que vas a ver al iniciar el sistema.
http://www.quanstro.net/newbie-guide.pdf
Si quieres programar en C. No te asustes, es mucho más simple de lo que crees.
http://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 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.).
https://gnu.org/software/guix/manual/html_node/Features.html#Features
https://gnu.org/software/guix/manual/html_node/Invoking-guix_002ddaemon.html#index-reproducible-builds
https://news.ycombinator.com/item?id=9747688
#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 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.
#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.
https://archive.fosdem.org/2015/schedule/event/stretching_out_for_trustworthy_reproducible_builds/
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.
$ cat /etc/debian_version
stretch/sid
¿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
.
Más información: http://c2.com/cgi/wiki?TheKenThompsonHack
#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?
https://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 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
https://reproducible.debian.net
blog de uno de los que esta revolviendo el tema
https://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.
#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