| 1 | # Windows cloud signing / Windows 云签名 |
| 2 | |
| 3 | Windows releases use Certum SimplySign. The repository needs `CERTUM_USERNAME`, |
| 4 | `CERTUM_OTP_URI` (the complete TOTP provisioning URI), and `CERTUM_KEY_ID` (the |
| 5 | 40-character SHA-1 certificate thumbprint). Never commit provisioning data. |
| 6 | The certificate private key remains in Certum's cloud. CI holds the credentials |
| 7 | needed to authenticate signing, so access to these secrets is signing authority. |
| 8 | |
| 9 | Windows 发布使用 Certum SimplySign。配置以上三个 Secret；不要提交二维码或 TOTP |
| 10 | 配置。证书私钥保留在云端，但 CI 凭据能授权签名，应按签名权限保护。 |
| 11 | |
| 12 | Run **Certum signing smoke test** on protected `main-v2`, approve the `release` |
| 13 | environment, and require successful login, signing, trust, signer and timestamp |
| 14 | verification. This test publishes nothing. The third-party login action is |
| 15 | pinned to an audited commit; authentication screenshots are disabled. Review |
| 16 | upstream code before updating the pin. |
| 17 | |
| 18 | 先在 `main-v2` 手动运行签名测试并批准 `release` 环境。测试不发布产物，必须通过 |
| 19 | 登录、实际签名、信任链、签名者及时间戳检查。第三方登录 Action 固定提交，更新前 |
| 20 | 需要审查，登录截图默认关闭。 |
| 21 | |
| 22 | Release builds retain native x64 and ARM64 startup tests. Their exact payloads |
| 23 | and generated NSIS identity files pass through same-run artifacts to serialized |
| 24 | x64 signing jobs. Those jobs sign the PE manifest, bind the minisign payload |
| 25 | manifest, rebuild packages, sign installers, verify portable hashes and expected |
| 26 | signer/timestamps, and only then produce final minisign-signed release bundles. |
| 27 | Any signing failure blocks publication and signing attestation. |
| 28 | |
| 29 | 正式发布保留 x64/ARM64 原生构建与启动测试，再将同一运行中的产物交给 x64 签名任务。 |
| 30 | 先签内部 PE 文件，再绑定清单、重打包、签安装器并验证便携包哈希，最后生成发布包。 |
| 31 | 任何签名失败都会阻止发布和签名证明。 |
| 32 | |
| 33 | The legacy `signpath-contract` command, `.signpath/contracts` location and |
| 34 | `SIGNPATH_RELEASE_SIGNING_ATTESTATION` variable remain as compatibility names for |
| 35 | existing release recovery. Their fingerprint now covers the Certum setup and |
| 36 | signer scripts; old attestations do not authorize this new signing path. No |
| 37 | SignPath API request is made by the release workflow. Historical receipt helpers |
| 38 | remain for investigating old runs. |
| 39 | |
| 40 | 旧契约命令、目录和证明变量名为恢复兼容而保留，但指纹已覆盖 Certum 实现，旧证明 |
| 41 | 不能授权新流程。发布不再调用 SignPath；旧回执工具仅供历史运行排查。 |
| 42 | |
| 43 | A successful standalone preflight uploads `verified-signing-contract-*` evidence |
| 44 | and prints the maintainer command for promoting its fingerprint to the recovery |
| 45 | variable in the job summary. `GITHUB_TOKEN` cannot modify repository variables; |
| 46 | the workflow does not need a privileged personal token. Promote only the exact |
| 47 | fingerprint from a run whose two Windows signing jobs succeeded. Official |
| 48 | orchestrated releases use successful same-run preflight evidence instead. |
| 49 | |
| 50 | 独立预检成功后上传 `verified-signing-contract-*` 证明，并在任务摘要中给出由维护者 |
| 51 | 将指纹写入恢复变量的命令。`GITHUB_TOKEN` 无权修改仓库变量，无需为此添加高权限 |
| 52 | 个人令牌。仅登记两个 Windows 签名任务均成功的运行所验证的准确指纹；正式编排发布 |
| 53 | 使用同一运行内的预检成功结果。 |
| 54 |