代理客户端是处理你全部网络流量的工具。如果下载的安装包被篡改——不管是 GitHub Release 页面被假冒、CDN 缓存被投毒，还是维护者账号被盗——你的所有流量包括密码、令牌和浏览记录都可能暴露给攻击者。GitHub Release 页面上提供的校验文件不是「给专业用户的高级功能」，而是每一个下载安装的人都该做的最基础步骤。

三层校验的关系：不是选一，是递进

校验层级防御什么不能防御什么操作耗时
SHA256 checksum文件在下载/传输过程中损坏或非恶意替换攻击者同时替换了 checksums.txt 和安装包30 秒
Cosign 数字签名checksums.txt 本身是否被替换（只有项目维护者私钥能签署）维护者的私钥泄露后签署的恶意文件2 分钟（首次安装 Cosign CLI + 验证）
SLSA ProvenanceCI/CD 构建过程是否被篡改（确认文件确实来自该仓库的 CI Workflow）源代码本身包含后门（如果恶意代码提交到了仓库，SLSA 无法检测）5 分钟（首次安装 slsa-verifier + 验证）

经验信号：2024-2025 年间出现了几起代理客户端 GitHub Release 被仿冒的事件——攻击者创建了同名但拼写略有不同的仓库（如 clash-verge-rev 变成 clash-verge-revo），Release 页面看起来一样但可执行文件是木马。SHA256 对比官方公告中的值可以瞬间识破这类攻击（攻击者无法伪造官方维护者的哈希值，除非他们同时控制了官方公告渠道）。

实践操作：SHA256 checksum 三步（所有用户适用）

以 sing-box v1.11.x 的 macOS 版本为例：

第一步：在 GitHub Release 页面的 Assets 区找到两个文件：

  • sing-box-1.11.0-darwin-amd64.tar.gz（安装包）
  • sing-box-1.11.0-darwin-amd64.tar.gz.sha256（checksum 文件，有时整合在 checksums.txt 中）

第二步：下载这两个文件到同一个目录。

第三步：终端运行比对：

# macOS / Linux
cd ~/Downloads
shasum -a 256 -c sing-box-1.11.0-darwin-amd64.tar.gz.sha256
# 输出: sing-box-1.11.0-darwin-amd64.tar.gz: OK

如果输出 OK，说明文件完整。如果输出 FAILED，不要打开这个文件，删除并从官方 Release 页重新下载。

Windows 上等效操作：

certutil -hashfile sing-box-1.11.0-windows-amd64.zip SHA256

然后将输出的哈希值与你下载的 .sha256 文件中的值肉眼比对。

进阶操作：Cosign 签名验证（确认文件来自项目维护者）

Cosign 解决的问题是：即使攻击者能在 GitHub Release 页上传一个假的 checksums.txt 和配套的假安装包，他没法伪造项目维护者私钥签署的 Cosign 签名。

前提条件：安装 Cosign CLI。

# macOS
brew install cosign
# Linux
curl -sSfL https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 -o cosign && chmod +x cosign && sudo mv cosign /usr/local/bin/

验证步骤：

# 下载签名文件和证书文件（通常命名为 checksums.txt.sig 和 checksums.txt.pem）
# 或者使用 keyless 模式（通过 GitHub OIDC 自动验证）
cosign verify-blob \
  --signature checksums.txt.sig \
  --certificate checksums.txt.pem \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity "https://github.com/用户名/仓库名/.github/workflows/release.yml@refs/tags/v1.11.0" \
  checksums.txt

如果验证通过，输出 Verified OK。此时你可以确认：checksums.txt 确实是由该仓库的特定 Workflow 在特定 Tag 处生成的，没有被替换。之后用 checksums.txt 中的 SHA256 值验证安装包。

对于没有提供 .sig/.pem 文件的项目，Cosign 验证无法进行——跳到只做 SHA256 比对。

SLSA Provenance 验证（确认构建流程没有被篡改）

SLSA Level 3 的 Provenance 文件记录了构建环境、源代码 commit hash、构建命令等不可伪造信息。它防御的场景是：攻击者入侵了 CI/CD Runner，在不修改源代码的情况下替换了编译输出。

# 安装 slsa-verifier
go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest

# 验证
slsa-verifier verify-artifact 下载的安装包 \
  --provenance-path 对应的.intoto.jsonl \
  --source-uri github.com/用户名/仓库名 \
  --source-tag v1.11.0

SLSA 验证目前在代理客户端项目中覆盖较少（sing-box 在部分 Release 中提供），是三层校验中最不普及的一层。如果你下载的客户端没有提供 Provenance 文件，跳过这步即可——SHA256 + Cosign 已经覆盖了绝大多数攻击场景。

建立常态化的下载安全习惯

习惯5 秒版本
确认仓库名称拼写打开 GitHub 仓库 URL，确认仓库名没有多余字符或字母替换（verge-rev 不是 verge-evo）
看 Star / Fork / Release 数量仿冒仓库的 Star 和 Fork 数通常远低于原仓库
在 Release Notes 中查找哈希值部分维护者会把 SHA256 写在 Release 正文里，这个位置的文字比 Assets 区的文件更难被攻击者通过上传文件替换
对比旧版本的签名如果你保留了之前版本的 Cosign 公钥证书，可以对比新旧证书是否来自同一个 Identity——证书突然变化可能是维护者密钥轮换（正常），也可能是攻击者接管了发布流程（异常）
不要从短链接或第三方转载下载始终从 GitHub Release 页面直接下载。短链接可能是钓鱼，第三方网盘/加速站的文件可能在传输过程中被替换

代理客户端的供应链安全在 2025-2026 年已经成为不可回避的话题。花 30 秒做 SHA256 校验、再花 2 分钟学一次 Cosign 命令，可能是你在整个代理使用链路中性价比最高的一次安全投入。如果你使用配套订阅线路，订阅链接本身的安全性也应该遵循同样的下载安全习惯——从官方渠道获取订阅地址，避免从不可验证的第三方转发获取。

未覆盖的校验方式

以下校验方式本文未覆盖：GPG 签名验证（通过 git tag -v 验证维护者的 GPG 签名；校验的是 Git Tag 而非 Release 二进制文件，两者是不同的校验对象）、Minisign/Signify 签名（部分项目使用而非 Cosign）、Windows Authenticode 签名验证、安卓 APK Signature Scheme v3/v4 验证、以及 iOS App Store 的代码签名。另外，构建环境的可重现（Reproducible Build）验证——确认相同源代码在同一构建环境中是否产生完全一致的二进制文件——是比 SLSA 更进一步的供应链安全保障，但目前代理客户端项目中尚未普及，不在本文操作范围。

相关阅读