Reproducible Firmware Build es una compilación en la que el mismo código fuente, entorno e instrucciones generan salidas predefinidas idénticas byte a byte. Deben indicarse la versión, el modelo del dispositivo y el alcance de la comparación, especialmente si la publicación contiene una firma adicional.
La afirmación se refiere a una salida determinada, como una imagen de firmware, no automáticamente a todos los archivos o registros. Un comportamiento equivalente del programa no basta: se buscan bytes idénticos, habitualmente mediante un hash criptográfico. El código abierto sin una compilación repetible no demuestra por sí mismo esa relación con el binario publicado. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Registre el commit exacto, las dependencias y sus versiones, el compilador, las opciones de compilación, las variables de entorno relevantes y el modelo de destino. No basta con el nombre del proyecto ni con una rama cambiante. La información necesaria para repetir la compilación debe publicarse o registrarse durante ella; de otro modo no pueden evaluarse las diferencias de forma fiable. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
Un compilador puede incluir la ruta del directorio de trabajo en la información de depuración. Dos ubicaciones del mismo código pueden producir archivos distintos. La ruta puede fijarse previamente o normalizarse mediante un procedimiento compatible. Esa regla debe formar parte de la receta; eliminar después diferencias desconocidas invalidaría la comprobación. [Reproducible Builds — Build paths]
Una firma válida vincula una publicación con su clave de firma dentro de un modelo de confianza. Una compilación independiente examina la relación entre el código y la salida binaria. El archivo oficial firmado puede incluir datos ausentes de una compilación local sin firma. Comparar sin más los archivos completos puede no ser la prueba adecuada de la reproducibilidad declarada. [Trezor — Reproducible build verification]
La documentación de Trezor selecciona una versión y un modelo, compila una imagen en el entorno indicado y la compara con la publicación oficial. Antes de comparar describe cómo poner a cero campos de firma definidos con precisión; los formatos antiguos también presentan diferencias en las cabeceras. La estructura depende del modelo y la versión. No debe aplicarse ciegamente el procedimiento de una imagen a otra, y la firma original debe verificarse por separado. [Trezor — Reproducible build verification]
Compruebe primero la revisión, el modelo, la variante de firmware, las dependencias y las transformaciones declaradas de la imagen. Conserve los archivos originales y un registro de la diferencia. La discrepancia puede deberse a un error de la receta o del entorno, o a un cambio del binario distribuido; por sí sola no identifica la causa. No dé la salida por verificada hasta explicar la diferencia y repetir la comprobación. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Un código defectuoso o malicioso puede ser perfectamente reproducible. Un compilador compartido no fiable puede introducir el mismo cambio en todos los resultados; repetir la misma herramienta no equivale a auditar independientemente el compilador. Los componentes binarios cerrados limitan lo que puede recompilarse del código disponible. La coincidencia tampoco verifica la autenticidad del hardware ni lo que está realmente instalado en un dispositivo concreto. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
Un registro útil indica quién compiló, desde qué commit, con qué receta, para qué modelo y qué archivos comparó. Incluya el algoritmo de hash, los resultados y las excepciones exactas para los datos de firma. Más personas que compilan de forma independiente reducen la dependencia de un único distribuidor, pero no sustituyen la revisión del código, del proceso de actualización ni de la seguridad integral del dispositivo. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Mismo código, distinta zona de firma
Dos personas compilan con el mismo commit, modelo y entorno. Sus imágenes locales tienen el mismo SHA-256; la imagen oficial firmada tiene otro. Si la documentación delimita exactamente los campos de firma, comparan copias tras la transformación prescrita. La coincidencia se refiere entonces al contenido así definido; la firma original se verifica aparte. No pueden eliminar sin más ninguna otra diferencia.
Para obtener la imagen más completa, lee esta entrada junto con Hardware Wallet, Clave privada, Cold Storage, Secure Element. También enlazan con esta entrada COLDCARD RNG Incident (2026).
01¿Un hash coincidente basta para concluir que el firmware es seguro?+
No. La coincidencia demuestra el resultado de una comparación concreta, no la ausencia de defectos. Un código malicioso o un compilador compartido no fiable pueden generar salidas idénticas. Deben distinguirse la verificación de la compilación, la revisión del código y la confianza en el dispositivo.
02¿Un hash diferente de una publicación firmada implica automáticamente un ataque?+
No. Una imagen firmada puede tener campos de firma o cabeceras distintos y documentados previamente. Verifique primero la versión, el modelo y el procedimiento de comparación correctos. Una discrepancia sin explicar no puede declararse una verificación satisfactoria ni eludirse borrando bytes arbitrariamente.