Reproducible Firmware Build 指使用相同源代码、环境和说明，生成预先确定、逐字节相同的输出。必须说明版本、设备型号和比较范围，尤其是在发布文件还包含额外签名时。
这一声明针对指定输出，例如固件映像，而非自动涵盖每个文件或日志。程序行为相同还不够：检查要求字节相同，通常借助密码学哈希。只有开放源代码却没有可重复的构建，并不能单独证明它与已发布二进制文件的对应关系。 [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
记录准确的 commit、依赖及其版本、编译器、构建选项、相关环境变量和目标型号。只有项目名称或不断变化的分支并不足够。重复构建所需的信息应当公开，或在构建时记录；否则就无法可靠地判断差异。 [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
编译器可能把工作目录路径写入调试信息。同一份源码放在两个位置，可能得到不同文件。可以预先指定路径，或采用工具支持的规范化方法。这项规则必须属于构建配方；事后删除未知差异会使验证失去意义。 [Reproducible Builds — Build paths]
在特定信任模型中，有效签名将发布文件关联到相应的签名密钥。独立构建检查的则是源码与二进制输出的关系。官方签名文件可能包含本地未签名构建中没有的数据。因此，直接比较完整文件，未必是检验所声明可复现性的正确方法。 [Trezor — Reproducible build verification]
Trezor 文档要求选择版本和型号，在指定环境中构建映像，再与官方发布文件比较。比较前，文档说明如何将准确界定的签名字段置零；旧格式的头部也可能不同。布局取决于型号和版本，不能把一种映像的步骤盲目用于另一种；原始签名必须另行验证。 [Trezor — Reproducible build verification]
先检查代码修订、型号、固件变体、依赖以及事先声明的映像变换。保留原始文件和差异记录。不一致可能来自配方或环境错误，也可能来自被改动的发行二进制文件；它本身不能确定原因。在解释差异并重新检查之前，不应把输出标记为已验证。 [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
存在缺陷或恶意逻辑的源码也能完全可复现。共同使用的不可信编译器可能把同一修改加入所有结果；重复使用同一工具不等于独立审计编译器。封闭的二进制组件会限制能从现有源码重建的范围。文件一致也不能验证硬件真伪，或具体设备中实际安装了什么。 [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
有用的记录应说明由谁构建、使用哪个 commit、按照什么配方、面向哪种型号，以及比较了哪些文件。还应列明哈希算法、结果和签名数据的准确例外范围。增加独立构建者可降低对单一发布者的依赖，但不能取代对源码、更新过程和设备整体安全的审查。 [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
代码相同，签名区域不同
两位构建者使用相同的 commit、型号和环境。本地映像的 SHA-256 相同，官方签名映像的哈希却不同。如果文档准确规定了签名字段，他们应在副本上执行指定变换后比较。一致性只针对这样界定的内容；原始签名另行验证。不能简单地删除其他任何差异。
要获得更完整的理解，请将本词条与以下词条结合阅读： Hardware Wallet, 私钥, Cold Storage, Secure Element. 反向关联还来自： COLDCARD RNG Incident (2026).
01哈希相同是否足以断定固件安全？+
不够。一致性证明的是某次具体比较的结果，而不是没有缺陷。恶意源码或共同使用的不可信编译器都可能生成相同输出。构建验证、源码审查和对设备的信任必须分别考察。
02签名发布文件的哈希不同，是否一定意味着攻击？+
不一定。签名映像可能具有事先说明的不同签名字段或头部。应先核对正确版本、型号和比较步骤。但不能把无法解释的不一致宣布为验证成功，也不能通过任意删除字节来绕过它。