scrcpy 发行版签名验证：用 GPG 与 SHA-256 校验官方发布包的完整指南

scrcpy 的所有发布版（server 与桌面客户端）都由维护者使用 GPG 签名。本文以仓库中的 发布签名验证文档 为核心，完整讲解如何导入签名公钥、核对指纹、验证校验和文件签名并逐一比对每个发布包的 SHA-256 摘要，并结合 release/ 目录下的构建与打包脚本，说明官方发布物（SHA256SUMS.txt 与 SHA256SUMS.txt.asc）是如何生成的。读完本文，你可以独立验证任意一个 scrcpy 版本发布包是否来自官方、是否未被篡改。

为什么需要验证发布包

README.md 在开头即明确提醒：请勿从随机网站下载 scrcpy 发布物，只应从官方渠道获取。发布包（尤其是 scrcpy-server，它会被推送到 Android 设备上运行）如果被植入恶意代码，风险将由使用者承担。因此官方为每个版本提供两个附加文件用于验证：

• SHA256SUMS.txt：所有发布文件的 SHA-256 校验和；
• SHA256SUMS.txt.asc：对上述校验和文件的 GPG 签名。

这套机制保证了两点：其一，只有持有私钥的官方维护者能生成 SHA256SUMS.txt.asc，验证签名即证明校验和文件本身可信；其二，校验和文件可信后，逐个文件比对 SHA-256 摘要即可证明每个下载文件的内容未被改动。

签名密钥信息

所有发布物使用 Romain Vimont 的 GPG 密钥签名，密钥详情如下（见 doc/verify-release.md）：

$ curl -s https://blog.rom1v.com/keys/rom1v.asc | gpg --show-keys --with-fingerprint --with-subkey-fingerprints
pub   rsa4096 2021-03-15 [C]
      4569 58E8 5A18 5DD5 C2D1  E4E8 0C82 2B29 8461 FA03
uid                      Romain Vimont <[e-mail]>
sub   rsa4096 2021-03-15 [S] [expires: 2030-05-14]
      E39E 2DE6 A55F 5AA6 D8EF  B79A CA01 F46F 1868 3B3D
sub   rsa4096 2021-03-15 [E] [expires: 2030-05-14]
      2C86 255E 6D65 241D 8248  F1B3 F212 10AE 292B 63D1
sub   rsa4096 2021-03-15 [A] [expires: 2030-05-14]
      1782 0F23 CB1D 1921 5572  6FAD 0F0B 58E1 3784 09AA

各子密钥的用途标注为：[S] 签名、[E] 加密、[A] 认证。验证发布包时真正用到的是签名子密钥 E39E2DE6A55F5AA6D8EFB79ACA01F46F18683B3D——后文验证输出的示例也印证了这一点。

第一步：导入公钥并核对指纹

有两种方式获取公钥（完整命令见 doc/verify-release.md）：

# 方式一：直接从维护者博客导入公钥
curl -s https://blog.rom1v.com/keys/rom1v.asc | gpg --import

# 方式二：从公共密钥服务器获取（按主指纹检索）
gpg --keyserver hkps://keys.openpgp.org --recv-keys 456958E85A185DD5C2D1E4E80C822B298461FA03

导入后，务必核对你本地密钥的指纹是否与上表中主密钥指纹 4569 58E8 5A18 5DD5 C2D1 E4E8 0C82 2B29 8461 FA03 完全一致：

gpg --fingerprint 456958E85A185DD5C2D1E4E80C822B298461FA03

指纹核对是防中间人攻击的关键环节：密钥服务器或博客上的密钥理论上仍可能被伪造，只有与官方文档公布的指纹逐字比对通过后，才能信任该密钥。

第二步：验证校验和文件的签名

将 SHA256SUMS.txt 与 SHA256SUMS.txt.asc 下载到同一目录后，执行：

# SHA256SUMS.txt 必须与 .asc 文件位于同一目录
gpg --verify SHA256SUMS.txt.asc

正常输出示例（doc/verify-release.md）：

$ gpg --verify SHA256SUMS.txt.asc
gpg: assuming signed data in 'SHA256SUMS.txt'
gpg: Signature made Wed Dec 17 20:16:30 2025 CET
gpg:                using RSA key E39E2DE6A55F5AA6D8EFB79ACA01F46F18683B3D
gpg: Good signature from "Romain Vimont <[e-mail]>" [ultimate]

判断要点：

• Good signature from "Romain Vimont <[e-mail]>" 表明签名有效且由已导入的该身份密钥作出；
• 使用 RSA key E39E2DE6A55F5AA6D8EFB79ACA01F46F18683B3D 表明签名由文档所列的签名子密钥生成，与第一步核对的指纹链路一致；
• 若输出 WARNING: This key is not certified with a trusted signature! 之类的警告，需要检查指纹是否匹配、密钥是否来自可信渠道，切勿直接放行。

第三步：逐文件比对 SHA-256 摘要

签名验证通过后，进入保存发布包的目录，执行：

# 各发布文件必须与 SHA256SUMS.txt 位于同一目录
shasum -a 256 -c SHA256SUMS.txt

Linux 系统通常还应使用 sha256sum -c SHA256SUMS.txt（shasum 是 macOS 等 BSD 系工具提供的名称）。正常输出示例：

$ shasum -a 256 -c SHA256SUMS.txt
scrcpy-server-v3.3.4: OK
scrcpy-linux-x86_64-v3.3.4.tar.gz: OK
scrcpy-win32-v3.3.4.zip: OK
scrcpy-win64-v3.3.4.zip: OK
scrcpy-macos-aarch64-v3.3.4.tar.gz: OK
scrcpy-macos-x86_64-v3.3.4.tar.gz: OK

只要出现任何 FAILED 或 No such file or directory，都不应使用对应文件。

官方发布包与校验和是如何生成的

验证流程的可靠性，建立在发布物确实按官方流程生成这一前提上。从仓库的发布脚本可以确认 SHA256SUMS.txt 的生成方式：

release/generate_checksums.sh 对固定的六个产物逐一计算 SHA-256 并写入 SHA256SUMS.txt：

sha256sum "scrcpy-server-$VERSION" \
    "scrcpy-linux-x86_64-$VERSION.tar.gz" \
    "scrcpy-win32-$VERSION.zip" \
    "scrcpy-win64-$VERSION.zip" \
    "scrcpy-macos-aarch64-$VERSION.tar.gz" \
    "scrcpy-macos-x86_64-$VERSION.tar.gz" \
        | tee SHA256SUMS.txt

这六个文件名与验证示例中的输出逐一对应。版本号来自 release/build_common，其取值逻辑为 git describe --tags --always，也支持通过环境变量 VERSION 覆盖——这解释了为什么发布文件名形如 scrcpy-win64-v3.3.4.zip。

release/release.sh 展示了完整的发布流水线：先运行 server 与 client 的测试脚本（test_server.sh、test_client.sh），再依次构建 server、Windows 32/64 位客户端、Linux x86_64 客户端，然后打包（package_server.sh、package_client.sh），最后才调用 generate_checksums.sh 生成校验和。从源码结构看，SHA256SUMS.txt.asc 的 GPG 签名是在该脚本之外、由维护者手动用私钥完成的——仓库内不包含私钥，也不应包含。

各平台的产物由对应的构建/打包脚本生成，例如 release/package_client.sh 将构建产物与 scrcpy-server 一起归档为 scrcpy-<target>-<version>.zip 或 .tar.gz，与 SHA256SUMS.txt 中列出的文件名命名规则一致。

与仓库中其他校验机制的呼应

官方对完整性的重视不止于 GPG 签名。install_release.sh 在下载预编译 server 后，会立即用硬编码的 SHA-256 值做一次独立校验：

PREBUILT_SERVER_SHA256=8588238c9a5a00aa542906b6ec7e6d5541d9ffb9b5d0f6e1bc0e365e2303079e
...
wget "$PREBUILT_SERVER_URL" -O scrcpy-server
echo "$PREBUILT_SERVER_SHA256  scrcpy-server" | sha256sum --check

这属于同一理念的简化版：脚本自身携带可信摘要，下载文件必须与其匹配才继续构建。区别在于它校验的是单个文件的摘要，而 doc/verify-release.md 描述的流程通过"先验签名、再验摘要"两步，把信任锚点放在了 GPG 公钥上，适用于任何数量的发布文件。

验证流程速查

将完整流程汇总为可复制的操作序列：

# 1. 导入公钥（二选一）
curl -s https://blog.rom1v.com/keys/rom1v.asc | gpg --import
# gpg --keyserver hkps://keys.openpgp.org --recv-keys 456958E85A185DD5C2D1E4E80C822B298461FA03

# 2. 核对主密钥指纹（应输出 4569 58E8 ... 8461 FA03）
gpg --fingerprint 456958E85A185DD5C2D1E4E80C822B298461FA03

# 3. 下载某版本的全部发布文件与 SHA256SUMS.txt(.asc) 到同一目录

# 4. 验证校验和文件的签名
gpg --verify SHA256SUMS.txt.asc

# 5. 逐文件比对摘要（Linux 用 sha256sum，macOS 用 shasum -a 256）
sha256sum -c SHA256SUMS.txt

适用前提与限制说明：该流程依赖 GnuPG（gpg 命令）、curl 以及 shasum/sha256sum 工具，在 Linux、macOS 及装有 GnuPG 的 Windows 环境均可执行；签名密钥当前标注的有效期至 2030-05-14，若未来密钥轮换，应以新版本文档公布的指纹为准，并重新执行指纹核对步骤。