2025-08-03,SSP Wallet v1.25.0 上线了两项改动,合在一起,补上了钱包分发中最古老、长期没人挑明的一处弱点:你不必再相信商店里的二进制就是仓库里的二进制。版本现在在 Docker 中以确定性方式构建,并以 GPG 签名。任何人 —— 不只是我们,不只是审计方 —— 都可以从源码重新构建,并验证所得文件与我们发布的逐字节一致。
不要相信,要验证 —— 应用到钱包二进制
比特币的口号「不要相信,要验证」通常用来谈交易。它以同样的力度适用于为交易签名的软件。一个钱包的代码可以开源、可以经过审计,仍然有可能发出被入侵的二进制,因为从代码到二进制要经过构建服务器、打包步骤、代码签名密钥与商店上传。任何一环都可能被投毒。泄露的 CI 令牌、流水线里被替换的二进制、被动过手脚的构建代理 —— 这些都触不到公开仓库,在 git log 里也看不出。
针对这种威胁模型的防御回答只有一个:二进制本身必须是可验证的。不是「我们保证可验证」,而是「陌生人可以重现」。
Docker 确定性构建
这正是 v1.25.0 提供的东西。每个 SSP 版本现在都在 Docker 容器中构建,基础镜像、工具链版本一并钉死,环境完全隔离。构建在不需要的地方没有网络访问,不会泄漏宿主机文件系统,不会把时间戳或机器路径烤进产物。输出是输入的确定性函数。
实际后果是:相同源码会生成相同二进制,校验和一致。取标签,在文档化的容器里、在你的机器上构建一次,你拿到的 SHA-256 与我们一致。如果不一致,标签与已发布二进制之间一定有什么发生了偏差 —— 这正是你想要的信号,因为唯一诚实的结果只有「二进制与源码对得上」或「对不上」。
这就是针对供应链攻击的缓解。它不假设构建服务器是诚实的,不假设开发者的笔记本是干净的,什么都不假设,并把核查工具递给陌生人。
GPG 签名的版本
可复现性告诉你「二进制对应某一棵源码树」,但它本身并不告诉你哪一棵源码树才是真的。GPG 签名解决的就是这件事。
v1.25.0 的每一件产物 —— 扩展包、校验和文件 —— 都用 SSP 的发布密钥签名。签名与版本一并发布在 GitHub 上。要校验一次下载,你只需导入一次公钥,对签名运行 gpg --verify,工具就会告诉你文件是否完整、签名的密钥是否就是你所预期的那一把。
两种机制相互组合。GPG 签名证明「这是 SSP 发布的那个文件」。确定性构建证明「这个文件对应这次提交」。它们合起来,关闭了提交与安装之间的信任缺口。
如何自己校验一个版本
GitHub 上的发布页是确切步骤的权威来源 —— 公钥指纹、签名文件名、用于复现构建的 Docker 命令。短版本:导入 SSP 发布密钥、下载校验和文件及其签名、对签名运行 gpg --verify,再用校验和对你下载的二进制运行 sha256sum -c。两步都通过,则产物完整、来源可信。
愿意走得更远的进阶用户可以克隆标签、运行文档化的 Docker 构建,确认得到的 SHA-256 与公布的校验和一致。绝大多数用户永远不会做这一步。重点是有一些人会做,只要他们之中任何一个发现了不一致,攻击就会立即暴露。
这带来什么变化
SSP 从 v1.0.0 开始就是开源的,自 2025 年初的全面复审起就已通过Halborn 端到端审计。v1.25.0 把那个三角形的第三条边也合上了。开源意味着你能读到代码;审计意味着专家看过代码;可复现加签名意味着你机器上跑的那一份,确实就是你读过的代码。
这三项保证彼此独立又相互组合。开源但不可复现的二进制仍然可以在构建流水线里藏有妥协。审计过但不可复现的项目仍然可以推出审计员没见过的篡改二进制。有了 v1.25.0,「安装前先验证」不再是口号,而是一份具体清单。
这就是一个自托管钱包的供应链故事,以唯一能被诚实讲述的方式被讲出来。