企业官网建设流程全解析

• 可观测性
• 运维
• 后端

导读

Pulse 的稳定版本发布链中包含一道 Windows Authenticode 代码签名关卡，当外部签名服务不可用时，发布流程必须显式降级而非悄悄绕过。本文基于 Pulse 仓库中的决策记录 v6.3.0-unsigned-windows-owner-approval-2026-08-22.md，完整还原该版本 "未签名 Windows 二进制获准发布" 的决策框架、约束条件与配套的完整性控制，并对照 代码签名策略、发布决策脚本与 GitHub Actions 工作流，说明这类例外如何被"版本绑定、逐次批准、其余安全控制不放松"地落地执行。读者将掌握：什么时候可以批准未签名 Windows 发布、批准后哪些完整性控制仍然强制生效、发布说明必须披露什么，以及从一次性例外到长期政策的演进路径。

决策上下文：为什么 v6.3.0 需要一份 Windows 签名豁免记录

Pulse 的 Windows 统一代理（Unified Agent）二进制在发布前需要经过 SignPath 的 Authenticode 签名。2026 年 8 月这个时间点上，SignPath 的生产签名链路并未就绪：根据集成记录 signpath-windows-authenticode-integration-packet-2026-07-21.md，SignPath 组织的Pulse [OSS]项目虽已获批接入、test-signing非发布签名集成证明也已完成，但生产用的Release certificate 2026一直停留在CSR PENDING（证书签名请求待签发）状态，导致release-signing策略对生产发布无效。换句话说：不是流程不愿意签名，而是外部证书没有签发，想签也签不了。

在这一前提下，如果机械地要求 "稳定版必须 Authenticode 签名"，v6.3.0 这个本身已通过质量评估的 GA 版本就会因外部依赖而无限期阻塞。2026-08-22，发布负责人（release owner）作出了明确决策：授权 v6.3.0 的稳定版发布未签名 Windows 统一代理产物，让不可用的签名通道不再阻塞本应放行的 GA 发布。这份决策被完整记录在 v6.3.0-unsigned-windows-owner-approval-2026-08-22.md，与同日记录的稳定版截止批准 v6.3.0-stable-cutoff-owner-approval-2026-08-22.md 构成 v6.3.0 GA 的完整决策包。

决策记录的核心元数据如下，这些字段在后续发布流程中都会被逐一校验：

决策性质：版本绑定的风险接受，而非永久豁免

这份记录最关键的定性在于它对自身边界的三重限定：

1. 不是签名成功的证据：记录原文明确说明这是 "version-bound risk acceptance, not evidence that Authenticode succeeded"——它只代表"接受未签名发布的风险"，绝不暗示 Authenticode 已经生效或成功。
2. 不是永久例外：决策自带失效条款。v6.3.1及以后的稳定版本自动恢复强制 Authenticode，除非发布负责人另行记录一份新的、明确版本绑定的决策。这意味着每一份豁免都是"一版一议"，后续版本不能自动继承。
3. 与同版本其他豁免相互独立：v6.3.0 同时存在另一份基于遥测数据的稳定版截止与缩短浸泡期批准（见 v6.3.0-stable-cutoff-owner-approval-2026-08-22.md）。这份签名豁免与那份截止豁免互不扩大、互不背书：签名豁免只放宽 Authenticode 一项，截止豁免只放宽浸泡时长一项，两个例外各自作用域分离。

从源码结构看，这种"版本绑定"约束在发布决策层被强制实现。在发布决策解析脚本 scripts/release_control/resolve_release_promotion.py 中：

• 常量WINDOWS_AUTHENTICODE_AVAILABLE = False全局宣告签名可用性状态（第 60 行）；
• 当调用方显式传入unsigned_windows_exception且当前并不存在长期豁免政策时，脚本会校验版本号白名单，仅允许6.1.0、6.1.1、6.1.2、6.2.0、6.2.1、6.3.0、6.3.1、6.3.2这些已获逐版批准的历史版本使用该例外，其余版本直接抛出ValueError，从机制上杜绝"未经逐版批准就跳过签名"。

完整性控制：未签名 ≠ 放松安全要求

决策记录明确指出，豁免"只改变 Authenticode 这一项要求"（"The exception changes only the Authenticode requirement"）。Windows 产物仍然必须满足以下强制完整性控制，任何一项都不能因为签名豁免而跳过：

• 精确发布 SHA 构建：产物必须由发布时的确切 commit（exact release SHA）构建，不允许从其他提交或漂移后的分支取二进制。
• 不可变候选清单绑定：产物必须绑定到不可变的候选 manifest（candidate manifest），清单内文件在发布全程不允许被替换。
• SHA-256 校验和：与产物一起发布，供下载方独立核验文件内容。
• 分离式.sig与.sshsig签名：Pulse 自身的发布签名体系不受影响，这两类分离签名继续对 Windows 产物生效，作为 Authenticode 缺席时的内容真实性兜底。
• 发布摘要验证：发布后必须对已发布摘要进行独立验证，防止产物与摘要被整体替换。
• 公开披露义务：公开发布说明必须写明 "Windows 二进制未经过 Authenticode 签名，可能显示未知发布者（Unknown Publisher）警告"，把风险如实告知每一位 Windows 用户，而不是让用户在安装时面对莫名其妙的系统警告。

在决策脚本层面，这项披露义务被强制化为硬校验：resolve_release_promotion.py中，只要unsigned_windows_exception（含长期政策生效）成立，就要求发布说明文本必须包含"not authenticode-signed"字样（不区分大小写），否则直接报错拒绝推进（第 422–430 行）。也就是说，想拿到豁免，就必须先把"未签名"这个事实写进公开说明，二者绑定，不可只取其一。

从构建工作流看，.github/workflows/release-dry-run.yml 在构建不可变候选时显式传入require_windows_signing: false（第 94–100 行），并在注释中要求该值与resolve_release_promotion.py中的WINDOWS_AUTHENTICODE_AVAILABLE保持对齐，且只能在发布负责人确认生产凭据与证书授权就绪后同时恢复。

从"一次性例外"到"长期不可用政策"：v6.3.0 → v6.3.2 的演进

v6.3.0 的豁免是逐版批准的第一代形态。三天后的 2026-08-25，因为生产签名链路依旧不可用，负责人进一步记录了 windows-authenticode-unavailable-owner-policy-2026-08-25.md，把处理方式从"每个版本单独批准"升级为"v6.3.2 起生效的长期不可用政策"。

这份政策引出了一个值得注意的失败模式：发布运行32896554952在构建并上传精确 SHA 的未签名 Windows 代理后，SignPath 生产release-signing提交被以Invalid request to SignPath API拒绝，且是在返回签名请求 ID 之前就被拒——这意味着连一条可追踪的请求记录都没有，失败任务的 rerun 无从收集。正因如此，负责人选择以长期政策收编这一状态：只要 SignPath 生产凭据与证书授权未恢复，新稳定版就不需要逐版修改未签名 Windows 白名单。

政策同时规定了恢复纪律：

• 禁止自动恢复：签名不能仅仅因为外部账号状态变化就自动重新启用，也不能"顺便"恢复；
• 恢复需显式确认：必须由发布负责人明确确认生产凭据与证书授权就绪；
• 恢复需走受审流程：恢复 Authenticode 需要经过评审的政策与代码变更，不能只是翻转一个开关。

在代码中，这套长期政策被实现为版本下限常量WINDOWS_AUTHENTICODE_STANDING_UNSIGNED_MIN_VERSION = (6, 3, 2)（resolve_release_promotion.py 第 61 行）：只要稳定版版本号 >=(6,3,2)且WINDOWS_AUTHENTICODE_AVAILABLE仍为False，standing_unsigned_windows_policy就自动成立（第 403–410 行），不再需要逐版手工传入例外参数；同时脚本会填入标准原因文本（第 419–420 行），说明 "SignPath 生产凭据与证书授权不可用，发布负责人已批准未签名 Windows 统一代理产物，直至可用性被显式恢复"。

发布说明与安装侧的用户视角

对最终用户而言，这一决策的可见影响有两处。第一处在发布说明：每个受影响版本的公开 release notes 都会包含 Windows 二进制未签名声明，下载时看到 "Unknown Publisher" 是预期行为而非异常。第二处在安装/回滚命令：决策记录给出精确回滚命令./scripts/install.sh --version v6.2.1，用户可以用它在需要时精确回退到上一稳定版；scripts/install.sh 本身就是安装脚本的权威实现，--version参数用于指定目标版本号，回滚目标v6.2.1与当前版本一样经过版本解析、清单绑定与完整性校验，而不是简单覆盖旧文件。

其他集成控制保持不变

决策记录最后强调，豁免不触及发布链的其他环节，以下正常集成控制全部原样保留：前端与后端构建、安装器、Docker、Helm、macOS 签名与公证（notarization）、候选验证、发布、激活与收敛控制。换言之，这是一次范围被刻意收窄的变更——只有 Windows Authenticode 一项被豁免，整个发布链的其他所有安全与质量关卡照常运转。

小结

Pulse v6.3.0 的未签名 Windows 发布授权记录是一份教科书式的"受控降级"样本：当外部签名依赖不可用时，与其让 GA 无限期阻塞，不如由负责人显式、逐版、有边界地接受风险，同时把完整性责任前移到发布说明披露、SHA-256 校验、分离签名、不可变清单与发布摘要验证等不依赖外部证书的环节。从 v6.3.0 的逐版批准，到 v6.3.2 起由 windows-authenticode-unavailable-owner-policy-2026-08-25.md 固化为长期政策，再到 resolve_release_promotion.py 中的版本下限与披露强制校验，这套机制回答了一个所有发布工程都会遇到的问题：当一项合规要求暂时无法满足时，如何既不放行无约束的发布，也不让外部故障永久卡死交付。

想要进一步了解签名通道的完整设计，可以继续阅读 代码签名策略（涵盖 SignPath 集成架构、GitHub 可信构建系统、SLSA v1 溯源与发布激活验证）以及 SignPath 集成记录（含测试签名证明的哈希明细与失败处理约定）。

• 可观测性
• 运维
• 后端