En Debian continúan esforzándose en hacer su distribución cada día más segura, en los últimos tiempos además de ofrecer versiones de soporte extendido (LTS), están dando pasos muy importantes para que la distribución de su software mediante paquetes binarios sea lo más fiable posible.
Ahí es donde entra el concepto de reproducible builds en Debian, los cuales tienen como objetivo garantizar que el código fuente de los programas y aplicaciones no se ha visto alterado durante su proceso de generación en binarios, lo que garantiza que no halla errores o incluso fallos malintencionados, por parte de las personas que empaquetan los programas que pudieran introducir debilidades de seguridad.
Ello se hace mediante un proceso que determina bit a bit si nuestro binario es el resultado del código fuente original y que no se ha añadido nada en ese proceso, permitiendo crear binarios idénticos de una determinada fuente en un entorno definido.
El concepto de reproducible builds también es una buena noticia para los desarrolladores que trabajen sobre versiones antiguas de software, especialmente a la hora de actualizarlos y detectar cualquier tipo de fallo que se hubiera producido a la hora de crear eses paquetes deb.
Es una idea en la que están muy interesados otras distribuciones GNU/Linux como Fedora, además de proyectos en los que la seguridad es un requisito como Tor o Bitcoin, y lo interesante en el caso de Debian es que en muy poco tiempo ha conseguido automatizar ese proceso de tal manera que ya abarca al 83,5% del total de sus paquetes disponibles en su rama sid (alrededor de 21 000 paquetes en total) tal como podemos leer en las listas de correo de la distro.
Hay que tener en cuenta que la cantidad de software disponible en Debian es inmensa, pero el objetivo de los desarrolladores es ambicioso y se espera que en próximas ediciones se continúe aumentando el porcentaje de builds reproducibles.
Imagen | Federico Mosquera (GPL-2.0+)
Creo que estoy me tiene un poco confundido. Si yo compilo un programa en un i5 me genera un ejecutable distinto si lo hiciera en un amd a4, entonces como puede asegurarse que dicho reproducible build está bien si ambos procesadores tienen instrucciones diferentes, etc. Debo decir que estoy pensando en modo gentoo (o Calculate Linux, específicamente).
No estoy muy puesto en el tema, pero lo que yo entiendo es que cada paquete perteneciente a una determinada arquitectura (i386, amd64, etc..) una vez sometido a este proceso debería ser exactamente igual a otro construido en las mismas condiciones.
Según la documentación esto es lo que define ese ambiente:
«-The architecture the package is built on (build architecture).
-The set of binary packages involved in the build. This includes Essential packages, build-essential, and Build-Depends and Build-Depends-Indep with the recursive dependencies for each packages.
-The path to the build directory. «
Muy bien, Debian a la vanguardia.
Depende que orden le des a gcc. Éste puede tomar las instrucciones propias con «march=native» para compilar exclusivamente para tu micro (tal como lo explicas) o establecer otro parámetro (i686, i586, amd64 o no escribirlo) para que sea genérico. Son cálculos matemáticos, no incluye donde fueron hechos a menos que lo especifiques.
era respuesta para carlosky77
con respecto al post, siempre me surgió la duda sobre si él código usado y disponible publicamente es efectivamente el que se compiló y no fue cambiado en el proceso. Siempre se confía en el desarrollador, pero pocas veces se guardan los enormes logs de compilación.
Pingback: El Proyecto Debian tiene un nuevo Líder | GUTL
Pingback: Tell the tale: A history of Reproducible Builds | Business Link Advertising