Bitcoin Core 安全策略详解：漏洞报告渠道、GPG 加密通信与版本支持周期

本篇技术指南基于 Bitcoin Core 仓库根目录的 SECURITY.md 展开，完整解析该项目的安全策略体系：漏洞应如何报告、如何通过 GPG 密钥与开发人员进行加密通信、以及版本支持周期（Supported Versions / End of Life）的运作机制。读完本文，你将掌握向 Bitcoin Core 团队提交安全问题的规范流程、可复制的 GPG 密钥导入与验证操作，以及官方披露安全修复的公开时间线。

一、安全策略的定位：文档在仓库中的位置

Bitcoin Core 在仓库根目录提供 SECURITY.md 作为官方安全策略文件。该文档虽然篇幅不长，但定义了三个关键要素：

1. 受支持版本（Supported Versions）：指明哪些版本的 Bitcoin Core 仍在接收安全更新；
2. 漏洞报告渠道（Reporting a Vulnerability）：安全问题的提交入口；
3. 敏感信息加密通信密钥：一组可导入的 GPG 公钥指纹，用于向开发人员加密发送敏感信息。

值得注意的是，仓库内还存在一个并列的、面向密码学库的安全策略：src/secp256k1/SECURITY.md，它为 secp256k1 库单独提供了独立的报告邮箱和独立的开发者密钥表。两者渠道不同，报告时应区分问题所属的组件范围。

安全策略并非孤立的文档，它直接参与发布流程。从 doc/release-notes-empty-template.md 可以看到，发布说明模板中明确写有 "In accordance with the security policy"（依据安全策略），说明每次发版时的漏洞披露行为都以该策略为依据。

二、支持版本：哪些版本仍在接收安全更新

SECURITY.md 的 "Supported Versions" 一节没有把具体版本号硬编码进文档，而是指向 Bitcoin Core 官网的生命周期（lifecycle）页面作为唯一权威来源。这样设计的工程理由在于：支持版本名单会随每个大版本发布而变化，将易变数据放在官网维护、文档只做引用，可以避免仓库文档与事实长期不一致。仓库中的发布流程文档印证了这一动态生命周期机制：

• doc/release-process.md 描述了大版本发布后的收尾动作：删除已 EOL（End of Life，结束支持）的发布分支并打 v${branch_name}-final 标签，同时清理对应已不存在分支的 "Needs backport" 标签；
• doc/release-notes-empty-template.md 的模板文本规定了 EOL 的判定口径：每当发布一个新的大版本，比该版本低 3 个及更早的版本即进入 "End of Life" 状态，不再接收任何更新。

因此，判断"我当前运行的版本是否还在安全支持范围内"的可靠方法是：查看官网 lifecycle 页面所列的支持版本列表，并结合上述"低 3 个版本 EOL"的规则理解其滚动窗口逻辑。

三、漏洞报告：提交入口与注意事项

SECURITY.md 给出了明确的报告方式：

To report security issues send an email to [e-mail] (not for support)。

即：向 [e-mail] 发送电子邮件报告安全问题，该邮箱仅用于安全问题，不处理常规支持请求。这一约束对使用者有实际意义：把非安全性质的 bug 报告、使用疑问发到该地址属于误用渠道。

若问题出在 secp256k1 库层面，src/secp256k1/SECURITY.md 提供了对应组件的专属渠道 [e-mail]，同样是 "not for support"。secp256k1 是 Bitcoin Core 的签名算法核心库（见 src/secp256k1 目录），其安全通告独立于主节点程序，两个邮箱分工清晰。

四、GPG 密钥：与开发者加密通信的完整操作

为了支持向开发人员传输敏感信息（例如未经公开披露前的问题细节、验证材料），SECURITY.md 列出了一组可供使用的公钥：

Name	Fingerprint
Michael Ford	E777 299F C265 DD04 7930 70EB 944D 35F9 AC3D B76A
Ava Chow	1528 1230 0785 C964 44D3 334D 1756 5732 E08E 5E41
Niklas Gögge	2CBB F208 E594 BF43 9B5F 276C 7465 CFFF 6793 242E

secp256k1 库另有独立的一组密钥（见 src/secp256k1/SECURITY.md）：

Name	Fingerprint
Pieter Wuille	133E AC17 9436 F14A 5CF1 B794 860F EB80 4E66 9320
Tim Ruffing	09E0 3F87 1092 E40E 106E 902B 33BC 86AB 80FF 5516
Sebastian Falbesoner	6A8F 9C26 6528 E25A EB1D 7731 C237 1D91 CB71 6EA7

4.1 导入公钥的标准命令

SECURITY.md 给出了可直接复制的导入命令，将 <fingerprint> 替换为上表中对应人员的指纹即可：

gpg --keyserver hkps://keys.openpgp.org --recv-keys "<fingerprint>"

文档特别强调：如果指纹中包含空格，务必用引号包住指纹。上表中的指纹按 GPG 惯例以两组形式排版（前 12 位与后 16 位之间有空格），因此在直接复制使用时，引号是防止 shell 将其拆分为多个参数、导致导入失败的关键。

4.2 实操要点

结合上述命令，完整的加密通信流程为：

1. 选择目标人员：根据问题所属组件选择密钥表——主程序问题用 SECURITY.md 中的密钥，secp256k1 问题用 src/secp256k1/SECURITY.md 中的密钥；
2. 导入公钥：执行上文的 gpg --recv-keys 命令；
3. 验证指纹：导入后应使用 gpg --fingerprint <keyid> 核对本机得到的指纹与文档所列值逐位一致，这是防止中间人伪造公钥的最低要求步骤。文档只提供指纹清单而不附带公钥文件本身，正是把"指纹比对"作为信任锚点；
4. 加密后发送：用导入的公钥对报告内容（或附件）执行 gpg --encrypt 后再通过邮箱渠道发送，确保未授权方无法读取敏感细节。

五、修复披露机制：发版后两周的公开时间线

安全策略的另一半是"官方何时公开已修复的漏洞"。这一点在 doc/release-notes-empty-template.md 的发布说明模板中得到了具体化，模板文本为每次大版本发布规定了固定节奏：

• 新大版本发布时，比它低 3 个及更早的版本进入 EOL，停止更新；
• 依据安全策略，两周后（"we will in two weeks disclose"）披露：
  • 修复在"低 2 个版本"（version minus 2）中的中高危（medium and high severity）漏洞，共 N 个；
  • 修复在当前版本（version）中的低危（low severity）漏洞，共 M 个。

这一节奏体现的是典型的"先修复发布、后延迟披露"策略：中高危修复先随版本发布给所有用户，留出两周缓冲期，再公开漏洞细节，降低"披露即遭利用"的窗口风险。对运维者的实际含义是：跟进官方发布说明（release notes）中的漏洞披露条目，是了解历史安全事件的标准渠道；仓库中保留了从 0.3.x 到 31.x 的完整历史发布说明，位于 doc/release-notes/ 目录。

六、策略的演进与维护

从 doc/release-notes/release-notes-0.19.0.1.md 的历史变更日志可以看到该策略的形成与修订过程："create security policy"、"update release process for SECURITY.md"、"Remove explicit mention of versions from SECURITY.md" 等条目说明：策略最初创建于 0.19.0.1 时期，随后经历流程对接，并最终移除了文档内硬编码的版本号——即当前"支持版本指向官网 lifecycle 页面"形态的由来。这一演进本身也印证了第二节所述的"文档只引用、官网存事实"的设计取向。

七、要点小结

• 报告入口：主程序安全问题发到 [e-mail]，secp256k1 库问题发到 [e-mail]，两者均明确 "not for support"；
• 支持范围：以官网 lifecycle 页面为准，滚动规则为"低于当前大版本 3 个及以上即 EOL"（doc/release-notes-empty-template.md）；
• 加密通信：按组件选择对应密钥表，用 gpg --keyserver hkps://keys.openpgp.org --recv-keys "<fingerprint>" 导入，注意含空格指纹必须加引号，导入后必须人工比对指纹；
• 披露时间线：中高危修复于"低 2 个版本"中完成，发版两周后经发布说明公开；低危修复随当前版本公开。

以上所有渠道、密钥与流程均以当前仓库 SECURITY.md、src/secp256k1/SECURITY.md、doc/release-process.md 与 doc/release-notes-empty-template.md 的实际内容为准；密钥指纹若随维护者变动，应以仓库文档的最新版本为唯一事实来源。