开源 VPN 客户端：代码能证明什么，不能证明什么

源码已经公开，许可证清楚，连接却依然无法端到端验证。这个缺口很普通，也不是丑闻。公开代码让一个组件可以被未被邀请的人检视，这是真实而不常见的性质。但这并不意味着你安装的二进制文件来自那份代码，也不意味着提供方在另一端运营的任何环节被审查过。

把组件与产品分开

有四样东西可以贴上开源标签，而它们很少全部开放。人们通常指的是客户端应用。它下面的协议实现是另一个产物，有时是库，有时是树内代码。服务器软件是第三个，提供方自己的基础设施、账户门户和支持工具是第四个。每一个都可以独立地开放或封闭。

所以“我们的应用是开源的”这类说法只描述了第一项，其余部分并未回答，这与其说不诚实，不如说是范畴滑移。有用的问题是：哪个仓库、在哪个标签上，对应你依赖的那个组件。

这一区分也解释了为什么两个拥有相同开放客户端的产品能给出差别很大的保证。客户端是你可以检查的部分；运营方的行为则需要用别的方式评估。

仓库是对意图的记录；磁盘上的二进制文件才是实际运行的东西。弥合这个缺口是机械性的工作，它从确认究竟安装了什么开始，而不是从下载页面宣传了什么开始。

Component	What inspection can show	What it leaves untouched
Client source	How profiles, packets and optional telemetry are handled	Whether the shipped binary matches that source
Build output	Whether a declared build reproduces a matching artefact	Whether the source is correct or the toolchain is clean
Server software	What the implementation is capable of logging	What the operator actually configures and retains
Account and support systems	Almost nothing, unless they are separately published	Everything about how those systems treat your data

包元数据告诉你版本和来源，这排除了包过期或被替换这种简单情形。它不会告诉你这个包是如何编译的，而可复现构建正是为回答这个问题而存在。可复现构建让独立第三方能够从同一份源码重新构建，并逐字节比较输出，于是不一致就变成了证据，而不是怀疑。

即便完全一致，能证明的也比人们期望的少。它表明产物与源码和构建配方相符，并不表明源码没有缺陷，也不表明所用的工具链值得信任。两者都值得知道，但它们是不同的断言。

dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wg

引发这类查阅的抱怨很少是“代码是封闭的”。通常是具体的观察：客户端向意外的地方发起连接、版本与发行说明不一致，或者支持流程索取了隧道本不该需要的东西。每一点都指向不同的组件。

客户端出现意外网络流量属于客户端源码的问题，可以通过阅读打开连接的代码路径来回答。版本不一致属于打包问题。支持流程索要身份文件属于账户系统的问题，再多的客户端审计也无法解决。

给组件命名，就把模糊的不信任变成了具体的检查。具体检查可以被回答、被争论，也可以被结案。替代方案是永远悬着、没有下一步的怀疑。

提供方服务器上的留存不在客户端能触及的范围。计费门户、欺诈检查供应商或保存附件的支持台的行为同样如此。把客户端审查拉伸成“我们审计了这项服务”，就是在做一个证据并不支持的断言。

读一读运营方公开的留存与请求说明，记下日期，并把它当作利害相关方的陈述，而不是测量结果。这是更弱的一种证据，明确说出这一差别，比在转述中抬高它更有用。

然后把手里的材料当作若干输入之一：所安装发行版本的标识、软件是否仍在维护、客户端如何配置，以及运营方对自己系统的说法。开放代码在一点上加强了这份评估。它并不替代其余部分。

审计声明应当始终说明其组件与版本。如果一份报告说不出它检查了哪个仓库、哪个构建，它描述的是意图，而不是产品。