PGP 在 1991 年出现时的目标很具体，让普通人也能用公钥加密保护邮件，密钥自己生成、自己保管，不依赖任何中心机构发放证书。它把信任判断交回使用者手里，代价是使用者得自己决定信谁。这套思路后来被 OpenPGP 标准化，也进入了软件发布流程，用来签发行包和容器镜像。今天签名的价值在于证明产物和某个密钥的对应关系，能挡住分发环节的替换，挡不住密钥被盗、构建环境被入侵、以及签名者身份判断错误这三类问题。
当时的动机是绕开中心化信任
那个年代的公钥体系大多建立在中心机构签发的证书上，机构不给你签，你就没法参与。PGP 的作者 Phil Zimmermann 想解决的是另一面，让持不同意见的群体、记者和普通用户在没有中心许可的情况下也能加密通信。密钥由本地生成，公钥通过点对点交换传播。
这种设计没有基础设施依赖，也意味着没有统一的可信根。信任网里判断一个人的公钥是否可信，要靠若干条签名链交叉确认，没有权威名单可以查。
信任网为什么没成为主流
信任网的问题在于判断负担。一个人收到陌生公钥，需要找到若干条自己能验证的签名路径，才能给这个公钥一个可信度。参与者少的时候这条路还行，人一多，签名图变得难以阅读，普通用户基本放弃验证。企业环境更倾向层级分明的证书体系，有明确的签发方和吊销流程，出事知道找谁。这种对比让 PGP 在邮件加密这一侧长期停留在小圈子，密钥服务器还出现过被大量伪造签名灌爆的情况。
代码签名这件事今天怎么做
发布流程里的签名逻辑比邮件加密更直接。维护者用私钥对产物签名，使用者用对应公钥验证产物有没有被改过。Linux 发行版的软件包签名、容器镜像签名、软件制品的发布签名都在这条线上，OpenPGP 是其中使用最广的格式之一。近几年出现了基于透明日志的签名方案，把签名事件记进一个可公开审计、只能追加的日志，验证者除了检查签名本身，还能确认它确实在某个时间点被记录过。
落地时的选择标准
- 只想确认下载到的安装包没被中途替换，产物签名加上校验步骤就够了。
- 需要让第三方独立验证构建来源，考虑带透明日志的签名方案。
- 还在用短密钥 ID 做验证，先把校验脚本改成按完整指纹比对。
- 团队没有密钥保管流程，先解决谁能签、私钥放在哪、离职后怎么换。
要把这套东西接进发布流水线，步骤大致是固定的。
- 生成一把专门的发布密钥，和开发者日常提交用的密钥分开。
- 在构建完成后对产物做签名，把签名文件和产物一起发布。
- 在下载页或者校验文档里给出完整指纹，供使用者比对。
- 把验签写进部署脚本，验证不通过就中止发布。
- 记录密钥的轮换和吊销计划，避免一把密钥用到失效。
签名能挡住什么，挡不住什么
签名的边界要写清楚。它能证明一段字节和一把密钥的对应关系，产出这份字节的过程它完全不管。
私钥泄露时签名照常有效。构建机被入侵，攻击者在签名之前把恶意代码塞进产物，签名验证一样通过。签名者身份判断错误时，验证方会替攻击者的密钥背书。密钥过期或被吊销后，历史签名的验证还要依赖时间戳和吊销信息，这两块做不完整，审计链条就断了。
常见问题
PGP 和 OpenPGP 是一回事吗。PGP 是早期实现的名称，OpenPGP 是后来的标准。
常见问题
PGP 和 OpenPGP 是一回事吗。PGP 是早期实现的名称，OpenPGP 是后来的标准。