从镜像站下载 VPN 安装包？先核实发布者

隧道能通，界面能起，会话稳定了一周。这些都不能说明安装包是谁构建的。VPN 客户端运行所需权限足以改写路由、读取凭据，所以发布者是威胁模型的一部分，而不是脚注。

按顺序逐项检查，遇到第一个不通过的就停下。这些检查都不贵，而且各自堵住不同的缺口。

第一步：从项目自己指定的渠道下载

每个项目都会说明其发布版本存放在哪里，那一页就是基准。社区构建、商店上架、厂商门户都是正当渠道。但每一种只有在项目本身指向它时才算正当。这就是检验标准，它和看起来像官方不是一回事。

以项目命名的文件证明不了什么。给安装包改个名只需一秒，而搜索结果最先展示的恰恰是名字。

第二步：用已知身份核验签名

签名验证能很好地回答一个范围很窄的问题。它告诉你某个身份签了这个二进制文件，且文件自那以后没有变过。它回答一个问题，却拒绝回答另一个。它无法告诉你那个身份是不是你想信任的那一个。

# macOS: who signed this app, and is the signature intact?
codesign -dv --verbose=4 /Applications/Tunnel.app
spctl -a -vvv -t install /Applications/Tunnel.app

# Windows: signature and publisher of the installer
Get-AuthenticodeSignature .\tunnel-setup.exe | Format-List Status, SignerCertificate

# Linux: detached signature from the project's release page
gpg --verify tunnel-1.4.2.tar.gz.asc tunnel-1.4.2.tar.gz

要看身份，而不是状态字样。一个无关的开发者只要有有效证书，同样能产出有效签名。操作系统报告“发布者已识别”，只说明有人花钱买了证书。

第三步：把哈希与独立来源比对

校验和只能证明与某个参考值一致。如果参考值就放在下载链接旁边，两者可以一起错，比对照样通过。多数教程里的失败模式正是如此。哈希和它所描述的文件往往在同一页上。

# Linux and macOS
shasum -a 256 tunnel-1.4.2.dmg

# compare against the value published on the project's own release page
# not against a value copied from the same mirror

如果项目发布的是已签名的校验和或已签名的发布清单，应当对整份清单验签，而不是逐个文件分别验签。这样一份可信基准就能覆盖整个发布版本。

安装之后：保留更新通道

安装结束后，受支持的渠道仍然重要。重新打包的构建可能自带更新器，而那个更新器决定下个月运行什么。从不更新的构建并不更安全，它只是更旧。

记录客户端应当如何更新，以及是否有管理系统负责这一步。如果答案是去论坛手动下载，供应链的问题就从未真正闭合。

两个来源，不是一个

客户端开发者与配置文件签发方是两个独立主体。官方客户端导入无关运营商的配置，是正常安排，而配置本身也值得单独审查：谁签发的、怎么交付的、服务器证书是否与预期名称一致。

在笔记里把两个来源都记清楚。一旦客户端被替换、设备从备份恢复，正是这两行信息能阻止一个来路不明的构建或配置随着其余数据一起回来。