| 1 | # Reasonix Windows SignPath 配置与验收 SOP |
| 2 | |
| 3 | 本文供 SignPath 管理员、GitHub 仓库管理员和 Release Maintainer 配置并验收 |
| 4 | Reasonix Windows Authenticode 两阶段签名链路。 |
| 5 | |
| 6 | 关联变更： |
| 7 | |
| 8 | - PR：[esengine/DeepSeek-Reasonix#6904](https://github.com/esengine/DeepSeek-Reasonix/pull/6904) |
| 9 | - 历史 Preview 渠道改造（仅供兼容背景）：[esengine/DeepSeek-Reasonix#6155](https://github.com/esengine/DeepSeek-Reasonix/pull/6155) |
| 10 | - 本 SOP 的验收对象：每次执行前通过 PR API 读回的当前 PR Head |
| 11 | - 签名工作流：`.github/workflows/release-stable.yml`、 |
| 12 | `.github/workflows/release-desktop.yml` |
| 13 | - 机器契约：`.signpath/contracts/release-signing.yml` |
| 14 | - Authenticode 验证脚本：`scripts/verify-windows-authenticode.ps1` |
| 15 | |
| 16 | > 如果 PR Head 已经发生变化，必须重新审查新的 commit 和 workflow diff， |
| 17 | > 不得继续使用本文记录的旧 SHA 进行正式 Secrets 验证。 |
| 18 | |
| 19 | ## 1. 目标与完成标准 |
| 20 | |
| 21 | 本次配置需要完成两阶段 Windows 签名： |
| 22 | |
| 23 | 1. 使用 `windows-payload` 给安装后实际落盘的 6 个 EXE 签名。 |
| 24 | 2. 使用 `windows-installer-v2` 验证这 6 个 EXE 已经签名，再给最终 NSIS |
| 25 | 安装器签名。 |
| 26 | |
| 27 | 完整放行标准： |
| 28 | |
| 29 | - `windows-payload` 和 `windows-installer-v2` 均已导入 SignPath 且状态为 |
| 30 | `VALID`。 |
| 31 | - 旧的 `windows-installer` 仍然存在并保持 `DEFAULT`，未被覆盖或删除。 |
| 32 | - `release-signing` 使用正式证书、Trusted Build System 和 Origin |
| 33 | Verification。 |
| 34 | - `release-signing` 保留证书强制要求的 SignPath 审批，但由专用 |
| 35 | `CI builds` 账号在对应 GitHub environment 获批后自动完成；发布人只需在 |
| 36 | GitHub 批准一次。 |
| 37 | - `test-signing-ci-approval` 和 `windows-installer-test-v2` 仅保留给内部签名 |
| 38 | 验证，不得被公共 Desktop 发布工作流引用。 |
| 39 | - AMD64 和 ARM64 均完成正式证书的零发布预检。 |
| 40 | - 首次单渠道正式版中，所有 Authenticode 签名均为 `Status = Valid`。 |
| 41 | - Windows Defender 环境下安装、启动、更新和卸载均通过。 |
| 42 | |
| 43 | ## 2. 管理员分工 |
| 44 | |
| 45 | | 角色 | 责任 | |
| 46 | | --- | --- | |
| 47 | | SignPath 组织管理员 / 项目 Configurator | 导入 Artifact Configuration，维护签名策略和 CI User 权限 | |
| 48 | | GitHub 仓库管理员 | 维护 Actions Secrets/Variables，必要时建立官方临时验证分支 | |
| 49 | | Release Maintainer | 批准一次 GitHub `release` environment，发布并验收正式版 | |
| 50 | |
| 51 | 如果现有维护者没有 SignPath 项目配置权限，组织管理员可以直接执行导入， |
| 52 | 或者在项目设置中将维护者或维护者组添加到 `Configurators`。 |
| 53 | |
| 54 | SignPath 权限说明： |
| 55 | [Users and permissions](https://docs.signpath.io/users/) |
| 56 | |
| 57 | ## 3. 当前配置基线 |
| 58 | |
| 59 | 截至 2026-07-25 的线上核对结果： |
| 60 | |
| 61 | - SignPath 组织：`DeepSeek-Reasonix [OSS]` |
| 62 | - SignPath 项目：`DeepSeek-Reasonix` |
| 63 | - 项目状态：`VALID` |
| 64 | - Repository URL： |
| 65 | `https://github.com/esengine/DeepSeek-Reasonix.git` |
| 66 | - 当前 Artifact Configurations： |
| 67 | - `Initial version` |
| 68 | - `windows-installer`，状态为 `DEFAULT` |
| 69 | - `windows-installer-test-v2` |
| 70 | - `windows-installer-v2` |
| 71 | - `windows-payload` |
| 72 | - `release-signing` 已开启 Trusted Build System 和 Origin Verification。 |
| 73 | - `release-signing` 开启 `Use approval process`，Required approvals 为 `1`。 |
| 74 | - `release-signing` 的 Allowed build definitions 精确允许： |
| 75 | - `.github/workflows/release-stable.yml` |
| 76 | - `.github/workflows/release-desktop.yml` |
| 77 | - `release-signing` 的 Allowed branches 必须精确为 `main-v2`；正式版标签由 |
| 78 | 最小 relay workflow 转发到该受保护控制面。 |
| 79 | - `test-signing-ci-approval` 使用测试证书，只允许 `CI builds` 提交和审批， |
| 80 | Required approvals 为 `1`，并启用相同的 Trusted Build、Origin 和 Build |
| 81 | Definition 限制。 |
| 82 | - `Release certificate 2026` 在证书 Restrictions 中启用了 |
| 83 | `Requires approval process`，因此该审批不能在项目策略中关闭。 |
| 84 | |
| 85 | ## 4. 授予 SignPath 配置权限 |
| 86 | |
| 87 | 如果由现有组织管理员亲自导入，可以跳过本节。 |
| 88 | |
| 89 | 1. 登录 SignPath。 |
| 90 | 2. 进入 `Projects`。 |
| 91 | 3. 打开 `DeepSeek-Reasonix`。 |
| 92 | 4. 进入项目编辑或项目权限设置。 |
| 93 | 5. 在 `Configurators` 中添加负责维护签名配置的用户或用户组。 |
| 94 | 6. 保存。 |
| 95 | 7. 重新打开项目。 |
| 96 | 8. 确认 `Artifact Configurations` 区域出现 `Add` 按钮。 |
| 97 | |
| 98 | 建议授权给维护者组，而不是长期绑定单个账号。 |
| 99 | |
| 100 | ## 5. 导入 `windows-payload` |
| 101 | |
| 102 | ### 5.1 获取固定版本 XML |
| 103 | |
| 104 | 必须从经过审查的 PR commit 复制文件，不要手工重新编写 XML： |
| 105 | |
| 106 | - 仓库路径： |
| 107 | `.signpath/artifact-configurations/windows-payload.xml` |
| 108 | - 固定版本： |
| 109 | [windows-payload.xml@fe354e5](https://github.com/SivanCola/DeepSeek-Reasonix/blob/fe354e59a9a076930403b7d8aefb0bcd0b4e182a/.signpath/artifact-configurations/windows-payload.xml) |
| 110 | |
| 111 | ### 5.2 导入步骤 |
| 112 | |
| 113 | 1. SignPath → `Projects` → `DeepSeek-Reasonix`。 |
| 114 | 2. 找到 `Artifact Configurations`。 |
| 115 | 3. 点击 `Add`。 |
| 116 | 4. 选择 `Custom`。 |
| 117 | 5. 名称填写： |
| 118 | |
| 119 | ```text |
| 120 | windows-payload |
| 121 | ``` |
| 122 | |
| 123 | 6. Slug 必须为： |
| 124 | |
| 125 | ```text |
| 126 | windows-payload |
| 127 | ``` |
| 128 | |
| 129 | 7. 粘贴上述文件的完整 XML。 |
| 130 | 8. 保存。 |
| 131 | 9. 确认配置状态为 `VALID`。 |
| 132 | 10. 点击 `Open XML`，逐字核对线上 XML 与仓库文件一致。 |
| 133 | 11. 不要将该配置设为 `DEFAULT`。 |
| 134 | |
| 135 | ### 5.3 配置含义 |
| 136 | |
| 137 | GitHub `upload-artifact` 提交给 SignPath 的产物是 ZIP，因此配置根节点必须是 |
| 138 | `<zip-file>`。 |
| 139 | |
| 140 | 该配置需要给以下 6 个 EXE 执行 `authenticode-sign`： |
| 141 | |
| 142 | - `reasonix-desktop.exe` |
| 143 | - `reasonix-guard.exe` |
| 144 | - `reasonix-launcher.exe` |
| 145 | - `reasonix-update-helper.exe` |
| 146 | - `reasonix-cli.exe` |
| 147 | - `reasonix-uninstall.exe` |
| 148 | |
| 149 | 参考： |
| 150 | |
| 151 | - [Artifact configurations](https://docs.signpath.io/artifact-configuration/) |
| 152 | - [GitHub trusted build system](https://docs.signpath.io/trusted-build-systems/github) |
| 153 | - [Artifact configuration syntax](https://docs.signpath.io/artifact-configuration/syntax) |
| 154 | |
| 155 | ## 6. 导入 `windows-installer-v2` |
| 156 | |
| 157 | ### 6.1 获取固定版本 XML |
| 158 | |
| 159 | - 仓库路径： |
| 160 | `.signpath/artifact-configurations/windows-installer-v2.xml` |
| 161 | - 固定版本： |
| 162 | [windows-installer-v2.xml@fe354e5](https://github.com/SivanCola/DeepSeek-Reasonix/blob/fe354e59a9a076930403b7d8aefb0bcd0b4e182a/.signpath/artifact-configurations/windows-installer-v2.xml) |
| 163 | |
| 164 | ### 6.2 导入步骤 |
| 165 | |
| 166 | 1. 再次点击 `Artifact Configurations → Add → Custom`。 |
| 167 | 2. 名称填写： |
| 168 | |
| 169 | ```text |
| 170 | windows-installer-v2 |
| 171 | ``` |
| 172 | |
| 173 | 3. Slug 必须为： |
| 174 | |
| 175 | ```text |
| 176 | windows-installer-v2 |
| 177 | ``` |
| 178 | |
| 179 | 4. 粘贴上述文件的完整 XML。 |
| 180 | 5. 保存。 |
| 181 | 6. 确认配置状态为 `VALID`。 |
| 182 | 7. 点击 `Open XML`，逐字核对线上 XML 与仓库文件一致。 |
| 183 | 8. 不要将该配置设为 `DEFAULT`。 |
| 184 | |
| 185 | ### 6.3 配置含义 |
| 186 | |
| 187 | 该配置需要： |
| 188 | |
| 189 | 1. 对最终的 `*installer*.exe` 执行 `authenticode-sign`。 |
| 190 | 2. 对上述 6 个内层 EXE 执行 `authenticode-verify`。 |
| 191 | |
| 192 | 如果任一内层 EXE 未签名，或签名后又被修改，第二阶段请求必须失败，不能继续 |
| 193 | 生成可发布的安装器。 |
| 194 | |
| 195 | 参考： |
| 196 | |
| 197 | - [Artifact configuration reference](https://docs.signpath.io/artifact-configuration/reference) |
| 198 | - [Projects and versioned configurations](https://docs.signpath.io/projects) |
| 199 | |
| 200 | ## 7. 保留旧配置 |
| 201 | |
| 202 | 导入完成后的 Artifact Configurations 应为： |
| 203 | |
| 204 | | 配置 | 预期状态 | |
| 205 | | --- | --- | |
| 206 | | `Initial version` | 保留 | |
| 207 | | `windows-installer` | 保留并继续为 `DEFAULT` | |
| 208 | | `windows-payload` | 新增、`VALID`、非 `DEFAULT` | |
| 209 | | `windows-installer-v2` | 新增、`VALID`、非 `DEFAULT` | |
| 210 | |
| 211 | 禁止执行以下操作： |
| 212 | |
| 213 | - 删除 `windows-installer`。 |
| 214 | - 将 `windows-installer` 的 XML 替换为新配置。 |
| 215 | - 修改旧配置的 Slug。 |
| 216 | - 将两个新配置设置为 DEFAULT。 |
| 217 | |
| 218 | 新工作流通过明确的 |
| 219 | `artifact-configuration-slug` 选择配置，不需要改变默认配置。保留旧配置是为了 |
| 220 | 保证旧 release ref 仍然可重跑。 |
| 221 | |
| 222 | ## 8. 检查并修正签名策略 |
| 223 | |
| 224 | ### 8.1 `test-signing` |
| 225 | |
| 226 | 打开 `test-signing` 并确认： |
| 227 | |
| 228 | - 使用测试证书。 |
| 229 | - Submitters 包含 `CI builds`。 |
| 230 | - CI 请求可以自动完成，不要求人工审批。 |
| 231 | - 如果启用 Origin Verification，仓库地址必须为： |
| 232 | |
| 233 | ```text |
| 234 | https://github.com/esengine/DeepSeek-Reasonix.git |
| 235 | ``` |
| 236 | |
| 237 | ### 8.2 `release-signing` |
| 238 | |
| 239 | 打开 `release-signing → Edit` 并设置： |
| 240 | |
| 241 | - Purpose：`Release signing` |
| 242 | - Certificate：正式 Release certificate |
| 243 | - Submitters：必须包含 `CI builds` |
| 244 | - `Require trusted build system`：开启 |
| 245 | - `Verify origin policy`：开启 |
| 246 | - Repository URL： |
| 247 | |
| 248 | ```text |
| 249 | https://github.com/esengine/DeepSeek-Reasonix.git |
| 250 | ``` |
| 251 | |
| 252 | - Allowed branches：**只能填写 `main-v2`** |
| 253 | - Allowed build definitions：**只能逐行填写以下两个精确路径**： |
| 254 | |
| 255 | ```text |
| 256 | .github/workflows/release-stable.yml |
| 257 | .github/workflows/release-desktop.yml |
| 258 | ``` |
| 259 | |
| 260 | 不得使用 `.github/workflows/release-*.yml` 通配符，也不得加入只负责转发 |
| 261 | dispatch 的 trigger workflow。仓库内 |
| 262 | `.signpath/contracts/release-signing.yml` 是该列表的机器可读事实源；CI 会 |
| 263 | 解析 workflow 调用图，发现新的顶层签名入口时失败关闭。 |
| 264 | - `Use approval process`：**保持开启** |
| 265 | - Required approvals：`1` |
| 266 | - Approvers：必须至少包含能够处理正式发布的 SignPath 人工审批人 |
| 267 | |
| 268 | 保存后重新打开策略，确认： |
| 269 | |
| 270 | - 策略状态为 `VALID`。 |
| 271 | - `Use approval process` 已开启。 |
| 272 | - Trusted Build System 和 Origin Verification 仍然开启。 |
| 273 | - Allowed branches 精确显示 `main-v2`，没有 `**`、`v*`、 |
| 274 | `desktop-v*` 或临时测试分支。 |
| 275 | - Allowed build definitions 与仓库机器契约逐项相同，没有通配符。 |
| 276 | |
| 277 | 正式版的 `vX.Y.Z` 标签事件由 `release-stable-trigger.yml` 转发：relay |
| 278 | 只携带候选 tag，实际顶层发布 workflow 固定运行在受保护的 `main-v2`，再签署 |
| 279 | `vX.Y.Z`、`npm-vX.Y.Z` 和 `desktop-vX.Y.Z` 共同指向的不可变候选 SHA。 |
| 280 | 不能把 Allowed branches 改成标签通配符，因为普通分支也可以取形如 |
| 281 | `v-malicious` 的名字。 |
| 282 | |
| 283 | `Release certificate 2026` 的 Restrictions 明确要求所有使用该证书的策略启用 |
| 284 | 审批流程。尝试关闭时，SignPath 会拒绝保存并提示： |
| 285 | |
| 286 | ```text |
| 287 | Certificate requires an approval process. |
| 288 | You can either enable the approval process or use another certificate. |
| 289 | ``` |
| 290 | |
| 291 | 因此不得关闭正式签名策略的审批。工作流先以 |
| 292 | `wait-for-completion: false` 提交请求，取得 Signing Request ID，再由专用 |
| 293 | `CI builds` 账号调用 SignPath `Approve` API，并轮询、下载签名产物。正式版 |
| 294 | 使用 `release-signing`；测试证书仅用于不发布产物的独立内部验证。 |
| 295 | |
| 296 | ## 9. 检查 GitHub Actions 配置 |
| 297 | |
| 298 | 进入： |
| 299 | |
| 300 | `Settings → Secrets and variables → Actions` |
| 301 | |
| 302 | 确认以下 Repository Secrets 存在： |
| 303 | |
| 304 | - `SIGNPATH_API_TOKEN` |
| 305 | - `SIGNPATH_ORGANIZATION_ID` |
| 306 | |
| 307 | 安全要求： |
| 308 | |
| 309 | - 不得在日志、截图、Issue、PR 评论或聊天中显示 Secret 值。 |
| 310 | - Token 对应的 SignPath CI User 应为 `CI builds`。 |
| 311 | - `CI builds` 必须具备 `release-signing` 的 Submitter、Approver 权限。 |
| 312 | 只有独立内部签名验证仍在使用测试策略时，才额外授予 |
| 313 | `test-signing-ci-approval` 权限。 |
| 314 | - 不得把个人 Interactive User 的 Token 用作 `SIGNPATH_API_TOKEN`。 |
| 315 | - `SIGNPATH_ORGANIZATION_ID` 必须指向正确的 OSS 组织。 |
| 316 | - GitHub `release` environment 的审批人仍然有效。 |
| 317 | - `release-signing` 的 Allowed branches 精确为 `main-v2`。 |
| 318 | |
| 319 | 正式验收前，应使签名契约 attestation 失效： |
| 320 | |
| 321 | ```bash |
| 322 | gh variable set SIGNPATH_RELEASE_SIGNING_ATTESTATION \ |
| 323 | --repo esengine/DeepSeek-Reasonix \ |
| 324 | --body unverified |
| 325 | ``` |
| 326 | |
| 327 | 这会使任何依赖旧 attestation 的 standalone 历史路径失败关闭。正式版不读取 |
| 328 | 旧 attestation 放行，而是在同一次获批运行中先完成真实签名预检，成功后才 |
| 329 | 启动 CLI、npm 和 Desktop 发布。 |
| 330 | |
| 331 | ## 10. 运行 AMD64/ARM64 正式证书零发布预检 |
| 332 | |
| 333 | Fork PR 工作流拿不到官方仓库的 SignPath Secrets，因此不能直接在 PR 分支 |
| 334 | 完成真实签名。不要为了合并前验证而放宽 `release-signing` 的精确 |
| 335 | `main-v2` 分支限制。代码、workflow 契约和无 Secrets 的打包测试在 PR 中 |
| 336 | 通过后，合并到受保护的 `main-v2`，再执行正式证书预检。 |
| 337 | |
| 338 | 零发布预检由 `.github/workflows/release-stable.yml` 在唯一的 `release` |
| 339 | environment 获批后自动调用。它使用 `release-signing` 和正式证书验证 |
| 340 | AMD64/ARM64，由 `CI builds` 自动批准 SignPath 请求，并跳过 publish job。 |
| 341 | 四个请求全部成功后，当前契约指纹会写入 |
| 342 | `SIGNPATH_RELEASE_SIGNING_ATTESTATION`。 |
| 343 | |
| 344 | ```bash |
| 345 | ./scripts/release-stable.sh X.Y.Z |
| 346 | ``` |
| 347 | |
| 348 | 该命令先验证远端 `main-v2` 的 reviewed Notes 和精确 SHA CI，再原子创建三个 |
| 349 | 正式版标签；随后 relay 启动受保护控制面。预检完成前，CLI、npm 和 Desktop |
| 350 | 三个公开 publisher 均不会启动，因此 SignPath 策略漂移不会形成半发布。 |
| 351 | 不要为了预检重新引入 Preview/RC 标签或 `canary` environment。 |
| 352 | |
| 353 | ### 10.1 监控运行 |
| 354 | |
| 355 | ```bash |
| 356 | RUN_ID="$(gh run list \ |
| 357 | --repo esengine/DeepSeek-Reasonix \ |
| 358 | --workflow release-stable.yml \ |
| 359 | --branch main-v2 \ |
| 360 | --event workflow_dispatch \ |
| 361 | --limit 1 \ |
| 362 | --json databaseId \ |
| 363 | --jq '.[0].databaseId')" |
| 364 | |
| 365 | gh run watch "$RUN_ID" \ |
| 366 | --repo esengine/DeepSeek-Reasonix \ |
| 367 | --exit-status |
| 368 | ``` |
| 369 | |
| 370 | ## 11. 正式证书预检验收标准 |
| 371 | |
| 372 | 以下两个任务必须同时成功： |
| 373 | |
| 374 | - `build (windows-amd64)` |
| 375 | - `build (windows-arm64)` |
| 376 | |
| 377 | 每个平台必须完成： |
| 378 | |
| 379 | 1. 构建未签名 payload。 |
| 380 | 2. 上传 payload。 |
| 381 | 3. 使用 `windows-payload` 签署 6 个 EXE；`CI builds` 自动记录审批。 |
| 382 | 4. 使用已签 payload 重新生成 portable ZIP 和 NSIS 安装器。 |
| 383 | 5. 上传 installer signing bundle。 |
| 384 | 6. 使用 `windows-installer-v2` 验证内层可信签名并签署外层安装器。 |
| 385 | 7. 执行 Authenticode release contract 验证。 |
| 386 | 8. `publish` job 因 `signing_preflight=true` 被跳过。 |
| 387 | |
| 388 | SignPath Signing Requests 中应出现 4 个成功请求： |
| 389 | |
| 390 | | 架构 | 第一阶段 | 第二阶段 | |
| 391 | | --- | --- | --- | |
| 392 | | AMD64 | payload 签名 | installer 验证及签名 | |
| 393 | | ARM64 | payload 签名 | installer 验证及签名 | |
| 394 | |
| 395 | 逐个检查： |
| 396 | |
| 397 | - 状态为 `Completed`。 |
| 398 | - Artifact Configuration Slug 正确。 |
| 399 | - Origin 指向官方仓库。 |
| 400 | - Commit SHA 与 GitHub Actions 运行 SHA 一致。 |
| 401 | - Trusted Build、Origin Verification、Malware Scan 均通过。 |
| 402 | - 自动预检和正常发布请求的批准 Actor 均为 `CI builds`。 |
| 403 | - AMD64 和 ARM64 的 payload、portable ZIP 内文件及最终 installer 均通过 |
| 404 | `Status = Valid` 信任链验证。 |
| 405 | |
| 406 | ## 12. 核对正式签名 attestation |
| 407 | |
| 408 | 只有以下条件全部满足后才能开启： |
| 409 | |
| 410 | - 两个新 Artifact Configuration 均为 `VALID`。 |
| 411 | - 旧 `windows-installer` 未改变。 |
| 412 | - `release-signing` 的证书级审批保持开启，正式审批人可用。 |
| 413 | - `release-signing` 的 Build Definitions 精确允许 |
| 414 | `.github/workflows/release-stable.yml`、 |
| 415 | `.github/workflows/release-desktop.yml`。 |
| 416 | - `release-signing` 的 Allowed branches 精确为 `main-v2`。 |
| 417 | - `CI builds` 是 `release-signing` 的 Submitter 和 Approver，GitHub Secret 使用其专用 |
| 418 | Token。 |
| 419 | - AMD64 和 ARM64 正式证书零发布预检全部成功。 |
| 420 | - 4 个 SignPath Signing Request 全部成功。 |
| 421 | |
| 422 | 预检会自动写入变量，只需读回核对： |
| 423 | |
| 424 | ```bash |
| 425 | gh variable get SIGNPATH_RELEASE_SIGNING_ATTESTATION \ |
| 426 | --repo esengine/DeepSeek-Reasonix |
| 427 | ``` |
| 428 | |
| 429 | 值必须为 `v1:` 加 64 位小写十六进制 SHA-256。只要 workflow、签名脚本、 |
| 430 | Artifact Configuration 或机器契约改变，CI 计算出的新指纹就不再匹配，必须 |
| 431 | 重新运行零发布预检。 |
| 432 | |
| 433 | ## 13. 首次单渠道正式版验收 |
| 434 | |
| 435 | 单渠道发布不再创建公开 RC。`signing_preflight=true` 在唯一的正式版 run 内 |
| 436 | 证明正式证书、双阶段产物链和自动审批闭环正确，成功后才允许同一 run 的公开 |
| 437 | publisher 启动。首次切换后的版本必须完整执行本文第 11、12、14 节以及仓库 |
| 438 | `docs/RELEASING.md` 的跨表面 postflight；不得用额外 prerelease 替代。 |
| 439 | |
| 440 | ## 14. 正式证书与 Defender 验收 |
| 441 | |
| 442 | 正式版 Windows 验证会启用 `RequireTrusted=true`。所有 Authenticode 签名必须 |
| 443 | 返回： |
| 444 | |
| 445 | ```text |
| 446 | Status = Valid |
| 447 | ``` |
| 448 | |
| 449 | 在干净的 Windows 11 AMD64 和 ARM64 环境中检查安装目录： |
| 450 | |
| 451 | ```powershell |
| 452 | Get-ChildItem "<Reasonix安装目录>" -Recurse -Filter *.exe | |
| 453 | ForEach-Object { |
| 454 | $signature = Get-AuthenticodeSignature $_.FullName |
| 455 | [PSCustomObject]@{ |
| 456 | File = $_.FullName |
| 457 | Status = $signature.Status |
| 458 | Subject = $signature.SignerCertificate.Subject |
| 459 | } |
| 460 | } |
| 461 | ``` |
| 462 | |
| 463 | 验收要求： |
| 464 | |
| 465 | - 安装器签名为 `Valid`。 |
| 466 | - 安装目录内全部 6 个 EXE 签名为 `Valid`。 |
| 467 | - Portable ZIP 内的可执行文件签名为 `Valid`。 |
| 468 | - AMD64 和 ARM64 的签名证书 Subject 符合预期。 |
| 469 | - Windows Defender 保持开启。 |
| 470 | - 实际完成安装、首次启动、CLI 调用、更新和卸载。 |
| 471 | - Windows Security → Protection History 中没有新隔离或拦截。 |
| 472 | |
| 473 | 只有 AMD64 和 ARM64 都通过，首次单渠道正式版才算完成验收。 |
| 474 | |
| 475 | ## 15. 失败处理与回滚 |
| 476 | |
| 477 | | 现象 | 处理 | |
| 478 | | --- | --- | |
| 479 | | 看不到 `Add` | 添加项目 Configurator，或由组织管理员直接导入 | |
| 480 | | XML 无法保存或状态不是 `VALID` | 只修复新配置，不修改旧 `windows-installer` | |
| 481 | | 内部 Test Signing Request 长时间 Pending | 检查测试策略审批配置、CI User、配置 Slug 和请求错误；公共 workflow 不得切换到测试策略绕过问题 | |
| 482 | | Release Signing Request 显示 Pending approval | 这是正式证书的强制门禁；由授权 SignPath 审批人在 Action 超时前处理 | |
| 483 | | Origin Verification 失败 | 核对仓库 URL、ref、SHA 和 GitHub Trusted Build | |
| 484 | | 提示文件缺失或存在额外文件 | 检查 signing bundle 与 XML 文件清单是否一致 | |
| 485 | | `authenticode-verify` 失败 | 检查内层文件是否未签名，或签名后被重新编译/修改 | |
| 486 | | 只有 AMD64 成功 | 不放行，ARM64 也是硬门槛 | |
| 487 | | 正式版签名不是 `Status = Valid` | 将 attestation 设为 `unverified`，停止后续发布并按不可变标签恢复缺失表面 | |
| 488 | | 自动预检请求等待人工审批 | 将 attestation 设为 `unverified`，检查 `CI builds` Approver 权限、API Token 和自动审批步骤；不得关闭证书强制审批 | |
| 489 | |
| 490 | 发生正式签名故障时，立即恢复失败关闭： |
| 491 | |
| 492 | ```bash |
| 493 | gh variable set SIGNPATH_RELEASE_SIGNING_ATTESTATION \ |
| 494 | --repo esengine/DeepSeek-Reasonix \ |
| 495 | --body unverified |
| 496 | ``` |
| 497 | |
| 498 | 在故障解除并重新完成 AMD64/ARM64 验收前，不得发布稳定版。 |
| 499 | |
| 500 | ## 16. 最终签字清单 |
| 501 | |
| 502 | - [ ] `windows-payload` 已导入且为 `VALID` |
| 503 | - [ ] `windows-installer-v2` 已导入且为 `VALID` |
| 504 | - [ ] 旧 `windows-installer` 仍存在并保持 `DEFAULT` |
| 505 | - [ ] 公共发布 workflow 未引用 `test-signing-ci-approval` 或 `windows-installer-test-v2` |
| 506 | - [ ] `CI builds` 是 `release-signing` 的 Submitter、Approver |
| 507 | - [ ] `SIGNPATH_API_TOKEN` 对应专用 `CI builds`，不是个人账号 |
| 508 | - [ ] `release-signing` 已开启 Trusted Build System |
| 509 | - [ ] `release-signing` 已开启 Origin Verification |
| 510 | - [ ] `release-signing` 的 Allowed build definitions 精确为 `.github/workflows/release-stable.yml` 和 `.github/workflows/release-desktop.yml` |
| 511 | - [ ] `release-signing` 的 Allowed branches 精确为 `main-v2` |
| 512 | - [ ] `release-signing` 的 SignPath 审批已开启，Required approvals 为 `1` |
| 513 | - [ ] GitHub `release` environment 的正式发布审批人和响应流程已经明确 |
| 514 | - [ ] AMD64 正式证书零发布预检两阶段签名成功 |
| 515 | - [ ] ARM64 正式证书零发布预检两阶段签名成功 |
| 516 | - [ ] 4 个 SignPath Signing Request 均为 `Completed` |
| 517 | - [ ] `SIGNPATH_RELEASE_SIGNING_ATTESTATION` 与当前机器契约指纹一致 |
| 518 | - [ ] 首次单渠道正式版的 AMD64 签名均为 `Valid` |
| 519 | - [ ] 首次单渠道正式版的 ARM64 签名均为 `Valid` |
| 520 | - [ ] Defender 安装、启动、更新和卸载验证通过 |
| 521 | - [ ] 签名稳定版已真实可下载后，再关闭对应问题单 |
| 522 | |
| 523 | ## 17. 参考资料 |
| 524 | |
| 525 | - [SignPath Artifact Configuration](https://docs.signpath.io/artifact-configuration/) |
| 526 | - [SignPath Artifact Configuration Syntax](https://docs.signpath.io/artifact-configuration/syntax) |
| 527 | - [SignPath Artifact Configuration Reference](https://docs.signpath.io/artifact-configuration/reference) |
| 528 | - [SignPath Projects](https://docs.signpath.io/projects) |
| 529 | - [SignPath Users and Permissions](https://docs.signpath.io/users/) |
| 530 | - [SignPath GitHub Trusted Build System](https://docs.signpath.io/trusted-build-systems/github) |
| 531 | - [Reasonix PR #6904](https://github.com/esengine/DeepSeek-Reasonix/pull/6904) |
| 532 |