这个场景解决什么
从网络拿到的二进制与镜像，落到本地之后应该走一遍校验流程：下载、核对摘要、验证签名。摘要（SHA-256）能发现传输损坏与内容被改动，签名（GPG）才能证明发布方身份。两者解决的是不同问题：只有摘要时，如果有人同时替换了安装包和摘要文件，你依然看不出问题。
基本信息
| 场景 | 验证下载产物的完整性与来源可信度 |
|---|---|
| 工具链 | curl 下载、sha256sum 校验摘要、gpg 验签 |
| 分层目标 | 摘要防损坏与常见篡改，签名防伪装发布方 |
| 必要前提 | 摘要文件与安装包来自同一发布渠道；签名公钥来自官方公布的指纹 |
典型使用场景
- 安装官方发行版镜像：下载后先校验摘要，再写入介质
- 部署第三方二进制：从发布页取包，核对摘要后入库或上线
- 内网分发：把文件与摘要一起同步到内网，接收方自行校验
- 镜像与容器制品：校验镜像导出文件，避免分发链路引入损坏
- 制度性要求：等保或内部规范要求安装包可追溯、可校验
下载与摘要校验
下载与摘要校验
curl -fLO https://download.example.com/app-v1.2.tar.gz # -f 遇 4xx/5xx 直接失败
curl -fLO https://download.example.com/app-v1.2.tar.gz.sha256
cat app-v1.2.tar.gz.sha256 # 确认格式：哈希 + 空格 + 文件名
sha256sum -c app-v1.2.tar.gz.sha256 # 输出 OK 才算通过
sha256sum --ignore-missing -c SHA256SUMS # 清单里有多个文件时只查已下载的
openssl dgst -sha256 app-v1.2.tar.gz # 不想依赖 sha256sum 时的替代写法签名验证
签名验证
gpg --verify app-v1.2.tar.gz.asc app-v1.2.tar.gz # 先验签，再看摘要
gpg --fingerprint ops@example.org # 核对指纹与官网公布值是否一致
gpg --keyserver keys.openpgp.org --recv-keys <完整指纹>
gpg --status-fd 1 --verify app-v1.2.tar.gz.asc app-v1.2.tar.gz | head # 便于脚本解析结果校验手段对照
| 手段 | 能防什么 | 不能防什么 |
|---|---|---|
| MD5 | 传输损坏的粗略检查 | 已被证明可构造碰撞，不应再用于安全场景 |
| SHA-256 摘要 | 传输损坏、非针对性篡改 | 摘要文件被一起替换的情况 |
| GPG 数字签名 | 篡改与伪装发布方 | 私钥本身泄露导致的问题 |
| HTTPS 传输 | 链路窃听与中间人替换 | 发布方源头的文件本身有问题 |
发布方同时提供摘要文件与签名文件时，两者都要验：先用签名确认摘要文件可信，再用它校验安装包。只贴一段哈希字符串的第三方下载页最容易被伪造，优先从官方仓库或官网取件。
gpg --verify 报 Good signature 但提示密钥未受信任时，结论是「签名与某把未知密钥匹配」，并不等于来源可信。此时必须人工核对指纹，不要用信任模型参数把它变成默认通过。