VPN 应用的可重现构建：一次匹配能证明什么
一致的重建把分发的二进制文件与声明的源代码和工具链绑定起来。它对该二进制背后的 VPN 服务或其日志没有任何说明。
可重现性是供应链的一种属性：相同的声明输入必须产生相同的产物。对 VPN 客户端而言，这句话把您下载的安装程序与任何人都能重建的源代码和工具链绑定起来。它对客户端所连接的服务没有任何说明。
因此有用的问题既狭窄又可以有答案。项目是否公布了流程，您手上这个具体的产物是否符合它？
构建在哪里不再确定
除非明确禁止，编译器会嵌入时间戳、绝对路径和构建主机名。归档会记录文件顺序和修改时间，链接器会随工具链版本改变输出，并行压缩可能重排数据块。上述任何一项都会让同一份源代码的两次构建在字节上不同，而并没有发生任何可疑的事。确定性是靠工程手段写进构建里的，从来不是默认继承来的。
声称可重现的项目必须说明它所采用的正规化：固定的时间戳、映射后的路径、排序后的归档条目、锁定版本的编译器和依赖。没有这份清单，就无法解释不一致，因为合法差异的范围没有被定义。
声明的输入也必须完整。没有标签的仓库 URL 不是修订版，没有哈希的锁定文件不是依赖集合，而在运行时下载工具的构建脚本带有一个谁也无法固定的输入。每一处缺口日后都会变成一处差异。在比较任何东西之前先把清单补全，因为不完整的清单无法以有意义的方式失败。
| Input | How it drifts | What pins it |
|---|---|---|
| Source | Branch moves after release | Commit hash in the build metadata |
| Toolchain | Compiler patch level differs | Container image digest |
| Packaging | Archive order and mtimes vary | Normalised archive settings |
比较实际检查的是什么
独立的一方在声明的环境中重新构建，并把输出与已发布的产物进行比较。逐位相同是强形式；有记录的正规化步骤，把已记录的差异反转之后结果吻合，是较弱但仍然有用的形式。
比较针对的是二进制文件。签名回答的是另一个问题：它把某个版本与某个密钥、某个密钥与某个身份关联起来，而项目完全可以在无人重建过的产物上拥有有效签名。这两项检查是叠加关系，而不是互相替代。
sha256sum wireguard-installer.msi gpg --verify wireguard-installer.msi.sig wireguard-installer.msi
安装之前把两者都跑一遍，并把哈希与同一版本、同一平台公布的哈希进行比较。与厂商页面一致的哈希证明下载完整到达；重建出的二进制与厂商公布的哈希一致，则证明了关于它如何被制作的更强的事情。
为什么不一致不等于被篡改
大多数不一致来自没有人控制过的输入。不同的编译器补丁版本、泄漏进调试符号的构建路径、改变了排序规则的区域设置，或是在比较之后才施加的打包步骤，都会产出与诚实工作不同的哈希。
所以不一致必须先对照有记录的流程来解读，然后才谈得上故事。如果流程把一切都固定住，而差异仍然无法解释，那就是真正值得向项目提出的发现。如果流程对打包只字未提，那差异完全可能是意料之中的。
这里对称性同样重要：匹配并不证明源代码没有缺陷。它只证明二进制与源代码相对应，而经过良好审计的代码和可重现的代码是两种不同的属性，一个项目可以只有其中之一。
这个主张对应用背后的服务说了什么
客户端是您设备上的程序；服务则是别处的服务器、账户体系和保留政策。可重现性约束的是前者，对后者一字不提，无论安装程序被验证得多么仔细。
端点配置在安装之后也可能改变，途径是远程设置或由提供商控制的配置文件。这些变更通过网络到达，您连接之前计算的任何哈希都覆盖不到它们。
按它实际的适用范围来读这个主张，然后单独检查相邻的那个问题：提供商记录了什么，又在哪个司法辖区下回应请求。经过验证的二进制和未经核实的服务完全可以并存，而这正是供应链检查被设计出来要让人看见，而不是要修好的情形。