Debian debe ofrecer paquetes reproducibles

 (lists.debian.org)
1 puntos por GN⁺ 5 시간 전 | 2 comentarios | Compartir por WhatsApp
  • El equipo de lanzamientos de Debian decidió, a mitad del ciclo de forky, exigir la entrega de paquetes reproducibles
  • El software de migración bloquea los paquetes nuevos que no se reproducen en reproduce.debian.net
  • La migración también se bloquea si aparece una regresión de reproducibilidad en paquetes ya existentes en testing
  • A los binNMU también se les añadió la ejecución de autopkgtest, igual que en las subidas source-full
  • La incorporación de loong64 y las reconstrucciones multi-arch aumentaron la cola de CI, por lo que se pide paciencia

Obligación de reproducibilidad en los paquetes de Debian

  • El equipo de lanzamientos de Debian decidió, en el punto medio del ciclo de lanzamiento de forky, que Debian debe ofrecer paquetes reproducibles
  • Esta decisión fue impulsada por los esfuerzos del proyecto Reproducible Builds
  • Desde el día anterior, se activó el software de migración para bloquear la migración de paquetes nuevos que no se reproducen en reproduce.debian.net
  • La migración también se bloquea cuando se produce una regresión de reproducibilidad en paquetes existentes que ya están en testing

Aseguramiento de calidad y responsabilidad de quienes suben paquetes

  • Ejecución de autopkgtest para binNMU en testing

    • A principios de este año, se añadió al software de migración la función de ejecutar autopkgtest también para binNMU, igual que con las subidas source-full
    • Puede que esta función no esté muy relacionada directamente con la mayoría del trabajo de los mantenedores, pero se considera otro paso para reforzar el aseguramiento de calidad

  • Incorporación de la arquitectura loong64 y aumento de la cola de CI

    • Hace dos semanas se añadió al archivo la nueva arquitectura loong64
    • Debian solo permite la migración de binarios construidos en buildd y, debido a los requisitos multi-arch, fue necesario reconstruir una cantidad considerable de paquetes en todas las arquitecturas
    • Debido a la función de binNMU añadida anteriormente, la cola de CI actual es bastante grande, y el equipo de lanzamientos pide un poco de paciencia

  • Seguimiento posterior a la subida

    • La persona que sube el paquete fuente tiene la responsabilidad de garantizar que ese paquete pueda migrar
    • Si un paquete queda bloqueado por una regresión de autopkgtest en una dependencia de prueba inversa y se necesita actualizar esa dependencia, quien lo subió debe presentar un bug con la gravedad RC correspondiente

Lecturas relacionadas

2 comentarios

 
GN⁺ 2 시간 전
Comentarios en Hacker News

  • Es un gran logro para Debian y el mundo del software libre.
    Aun así, tomó bastante tiempo que se entendiera la necesidad. Incluso cuando en 2007 se dijo en debian-devel que esto era necesario, respondieron que era una enorme pérdida de tiempo, y en efecto hizo falta una cantidad inmensa de trabajo de mucha gente para llegar hasta aquí, pero valió totalmente la pena.

    • Desde 2007 no ha habido en Debian ningún bug o ataque que los paquetes reproducibles pudieran haber evitado.
      No creo que sea correcto decir que “valió la pena”. Solo eleva más la barrera de entrada para contribuir a Debian, y ya he visto a mucha gente quejarse de lo difícil que es contribuir. Antes lo defendía con el argumento de que “hace falta todo tipo de validaciones y controles para que los paquetes encajen bien entre sí”, pero esto parece hacer las cosas más difíciles sin mucha razón, y con un beneficio pequeño.

  • Hay más información en https://wiki.debian.org/ReproducibleBuilds. Parte está desactualizada, pero también hay gráficas que muestran la cantidad de paquetes construidos en CI y cuántos de ellos tienen builds reproducibles.
    El color naranja significa FTBR, o sea “falló al construir de forma reproducible”. No soy muy bueno leyendo números en gráficas, pero calculo que son unos pocos puntos porcentuales, como 4~5%.

    • A mí solo me aparece esto:

      Forbidden

      You are not allowed to access this!
      Incluso me salen las etiquetas HTML tal cual :)
      Edit: también encontré la página “I Challenge Thee” en el historial. ¿Será que me bloqueó alguna medida anti-bots? ¿Por qué???

  • Está muy bien. NetBSD tiene builds completamente reproducibles desde 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • Como dice el enlace, NetBSD lo logró con ayuda de Debian. Si entendí bien, no fue tanto porque NetBSD se esforzara más, sino porque el problema era más fácil. Tiene menos paquetes y cambia menos. Todavía usan CVS, así que decir “estabilidad” se queda corto.
      Por cierto, la mayoría de los paquetes de Debian ya tienen builds reproducibles. Los que no, alrededor de un 5%, aparecen en naranja en esta gráfica: https://wiki.debian.org/ReproducibleBuilds
    • Para presumir un poco, stagex fue el primero en lograr el año pasado builds deterministas y aislados basados en bootstrap 100% desde código fuente de todo el sistema, y también el primero en exigir para cada release múltiples reproducciones firmadas, hechas por distintos mantenedores en su propio hardware.
      Debian ha avanzado mucho, pero cuando Debian dice que es reproducible, eso significa que obtiene binarios de terceros para hacer sus propias builds. Cuando nosotros decimos reproducible, queremos decir que hacemos bootstrap desde código fuente al 100% hasta el final de toda la cadena de suministro de software.
      Creo que esa diferencia sí importa.
      https://stagex.tools

  • De verdad me da gusto este cambio. En 2021, después de leer sobre el ataque de SolarWinds y quedarme impactado, empecé a involucrarme en builds reproducibles. [1]
    Creo que la mejor forma de decirlo es como lo expresó Magnus Ihse Bursie, que trabajaba en builds reproducibles de OpenJDK: “Si me preguntan, el simple hecho de que en algún momento los compiladores y herramientas de build empezaran a producir salidas no deterministas ya era un bug desde el día uno”. [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • Me pregunto por qué esto se está volviendo tema justo ahora. Uso Yocto para dispositivos embebidos, y los builds reproducibles casi se podían implementar por defecto.
    Como además la gestión de paquetes de Debian se puede activar fácilmente, da la impresión de que esto ya debería haber sido posible desde antes.

    • Me pregunto qué quieres decir con “por qué esto es tema ahora”.
      Los builds reproducibles son una práctica esencial en la computación industrial. Más que Debian esté a la vanguardia en este campo, se parece a que está adoptando una técnica ya extendida en toda la industria y aplicada también en otros sistemas operativos usados en operación a largo plazo y contextos relacionados con seguridad.
      Claro, también hay mucho que hoy ya usamos con facilidad gracias al trabajo difícil de muchos desarrolladores de Yocto y Debian.
      Lo interesante es que ahora los desarrolladores de Debian lo están aplicando como una política más decidida, haciéndolo no una opción sino la norma por defecto.
    • Me pregunto si de verdad se verificó activamente que el build sea reproducible a nivel de bits.

  • En amd64 forky:
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    Estas estadísticas, las de otras arquitecturas y las razones de la no reproducibilidad se pueden ver en https://reproduce.debian.net

  • Siempre me sorprende que Debian esté impulsando esto y no un vendor comercial. Uno pensaría que las grandes organizaciones que pagan por RHEL y Ubuntu exigirían con fuerza binarios verificables.

    • Si un competidor pudiera demostrar que su paquete es idéntico a nivel de bits al que distribuye una gran organización, ese competidor podría beneficiarse de las garantías de seguridad de esa gran organización.
      Eso es muy bueno para el software libre, pero no tanto para quien quiera ser un monopolista.
    • Los builds reproducibles existen para reducir la necesidad de confianza, pero los vendors comerciales viven de vender confianza.

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 시간 전
Comentarios en Lobste.rs

  • Es un buen cambio desde la perspectiva de seguridad. La transición puede ser engorrosa, pero al final brindará mayor confiabilidad a los usuarios de Debian Linux en todo el mundo

  • Me pregunto cuál es el beneficio clave para un proyecto como Debian. ¿La idea es que todos puedan tener pruebas de que no hay puertas traseras en los binarios?
    O sea, ¿que esto reduzca la confianza que se le exige al mantenedor y también el riesgo de mantenedores maliciosos? No es que sea escéptico, solo que no entendía al 100% por qué Debian dedica tanto tiempo a esto. Hacer que una compilación sea reproducible parece bastante difícil y laborioso

    • Permite verificar no solo puertas traseras, sino también si hubo manipulación o modificaciones en general. Eso ayuda a la seguridad y también tiene ventajas para el desarrollo del proyecto, porque los paquetes que se compilan de forma reproducible y de manera relativamente aislada tienen menos probabilidades de romperse de formas extrañas en otros entornos de desarrollo
      La clave es proporcionar artefactos de prueba de que el paquete resultante realmente proviene de ese código fuente específico, y no de un segundo conjunto de fuentes oculto. the reproducible-builds org has a bit of a 'why' which puts it better than i can
      Hacer compilaciones reproducibles es muy difícil. Por ejemplo, hasta las marcas de tiempo dentro de la tubería de compilación pueden generar diferencias, y lo mismo pasa con los metadatos de los archivos generados. Hay que eliminar todo eso y, en algunos casos, no se necesita un parche para el paquete en sí, sino para proyectos upstream como CMake o el compilador de Go. En muchos casos, antes ni siquiera se consideraban este tipo de problemas, así que hace falta trabajo a lo largo de toda la pila de compilación. Dicho eso, este trabajo viene avanzando desde hace mucho tiempo, así que buena parte de la infraestructura subyacente ya está terminada o muy avanzada
    • No creo que esto deba ser la máxima prioridad de Debian, pero Debian no funciona así. La gente hace lo que quiere hacer, y las prioridades individuales muchas veces no coinciden bien con prioridades razonables a nivel del proyecto

  • ¿La reproducibilidad de la que habla Debian es el mismo concepto del que se habla en lugares como NixOS?

    • No. NixOS is not reproducible es la referencia estándar
    • Las distribuciones que siguen las compilaciones reproducibles como proyecto en general avanzan hacia el mismo objetivo. reproducible-builds.org sigue a los proyectos que están trabajando activamente en esto dentro de su pipeline de empaquetado
      NixOS también está trabajando en compilaciones reproducibles, y si no recuerdo mal, al menos la ISO es 100% reproducible tanto en compilación como en ejecución. Pero la reproducibilidad de la que se suele hablar con NixOS no es la de “compilaciones reproducibles” que se discute aquí. Ve el artículo de foxboron enlazado en un comentario hermano de este hilo. Eso se parece más a reproducibilidad del entorno, o a “compilaciones deterministas”, y sigue siendo valioso, pero no es de lo que se está hablando aquí

  • Por ahora, esto suena como un enfoque de trinquete. ¿Las cosas que nunca antes se han compilado de forma reproducible siguen permitiéndose?

    • Si un paquete no se compila de forma reproducible, no se incluye en la siguiente versión de Debian. O sea, los paquetes que “nunca antes se han compilado de forma reproducible” pueden seguir en Debian unstable, pero no se ve con buenos ojos mantener en Debian unstable paquetes que no llegan a stable. Aun así, tengo entendido que no existe una regla aplicada de forma mecánica