100 lines
8.0 KiB
Markdown
100 lines
8.0 KiB
Markdown
# RC-06 单审核人一键初始化与签署操作说明
|
||
|
||
更新时间：2026-09-27
|
||
|
||
## 1. 适用范围与当前状态
|
||
|
||
本工具只处理 RC-06 的一个精确发布批次：60 个合同资产、14 个 Prompt 模块和 31 项处置结论。唯一人工审核人为陈钰麒（总经理）。离线根密钥和 apply 服务密钥由系统按用途隔离管理，它们不是人工审核人。
|
||
|
||
陈钰麒已在受控本机完成审核密钥初始化；该事实只表示审核私钥已加密保存并完成公钥注册准备。RC-06/recovery/apply 技术密钥、源码 pin、正式签名、候选 tag、发布收据和生产授权仍未形成。内部试点、UAT、生产及公众开放继续 `NO_GO`。一次 RC-06 签名不等于资产已经发布，也不等于授权公众生产切流。
|
||
|
||
## 2. 审核人只需要执行的两个入口
|
||
|
||
### 2.1 首次初始化
|
||
|
||
候选冻结前，由陈钰麒在受控 Windows 电脑上双击：
|
||
|
||
`yuqei-infra\scripts\Initialize-ReleaseSigner.cmd`
|
||
|
||
工具会：
|
||
|
||
1. 将加密 Ed25519 审批私钥保存在当前 Windows 用户的 `%LOCALAPPDATA%\Yuqei\ReleaseSigner\keys`；
|
||
2. 要求输入并再次确认不少于 20 个字符、非纯数字且不可过于简单的长句口令；
|
||
3. 生成可交给系统使用的公钥注册材料和公钥指纹；
|
||
4. 拒绝把私钥写入源码仓库、OneDrive、网络目录、符号链接或不属于当前账户的目录，并将目录、私钥和操作锁的 owner/DACL 收紧到当前账户与 SYSTEM；
|
||
5. 重复运行时验证已有密钥，不覆盖或偷偷换钥。
|
||
|
||
口令只在本机遮罩输入，不通过命令行、环境变量、密码文件、聊天或日志传递。私钥不得上传仓库、服务器、邮件、聊天、共享盘或 CI artifact。
|
||
|
||
双击入口只选择本机已安装、带 Python Software Foundation 有效签名且具备所需密码库的离线 Python 运行时；以 `-I -S -B` 隔离模式启动，忽略 `PYTHONPATH`、user-site、`sitecustomize` 和安装器别名，不联网安装或更新运行时。若不存在合格运行时，工具会在输入口令前停止。
|
||
|
||
### 2.2 最终批次签署
|
||
|
||
只有在系统已配置长期 root/apply-service 公钥指纹和候选精确 keyring epoch、形成唯一 commit/tag/source manifest、由离线根签发绑定该 manifest 原始 SHA 的候选专属 keyring，并完成同一候选 BUILD 与 RC-05 后，系统才会在本机 signer inbox 放入唯一待审请求。届时由陈钰麒双击：
|
||
|
||
`yuqei-infra\scripts\Approve-ReleaseCandidate.cmd`
|
||
|
||
工具会自动校验候选、root 签名 keyring、keyring 对精确 manifest 原始 SHA 的授权、冻结 root/apply pin、epoch、时窗、60/14/31 清单及 RC-05 终态，然后显示一页中文摘要。陈钰麒只需：
|
||
|
||
1. 核对候选 commit/tag、manifest 原始 SHA、payload SHA、60/14/31 数量和 RC-05 状态；
|
||
2. 输入摘要显示的 6 位批准码；
|
||
3. 输入本人审核密钥口令一次。
|
||
|
||
工具在批准码和口令输入完成后重新取得当前时间并重读全部材料，生成最长 24 小时的批准，再自动裁剪到请求、审批密钥、keyring 和全部风险接受的最早到期时间；用户不能手工填写审批时间或身份。签名写出前会调用正式 RC-06 验证器自验，并以完整 staging＋禁止覆盖的原子发布写出收据。系统会先认证并归档不同候选留下的过期请求；失败、取消、错误口令、文件漂移、多个仍有效请求或 pin 未配置都不会留下正式收据。
|
||
|
||
成功后待审请求自动移入 `processed`，不会阻塞下一候选。重复双击会自动复验已有收据并提示“此前已签署，无需重复操作”，不会再次签名或覆盖文件。
|
||
|
||
## 3. 系统自动完成的工作
|
||
|
||
- 生成并管理与审核密钥不同的离线根密钥和 apply 服务密钥；
|
||
- 在源码冻结前固定长期 root 公钥、候选精确 keyring epoch 和 apply 服务公钥指纹；任何 keyring 轮换或撤销都必须使原候选失效并重新冻结；
|
||
- 在 manifest 形成后，用根密钥签发只包含陈钰麒审批公钥、并授权该 manifest 原始 SHA 的候选专属 trusted keyring；keyring payload 不写回源码，避免候选 commit 与 keyring 形成哈希循环；
|
||
- 生成不可变 RC-06 manifest 和待审请求；
|
||
- 用户签名后验证 approval v4 / payload v3；payload 同时绑定候选精确 keyring epoch 和 root 签 keyring payload SHA；
|
||
- 后续通过业务 API 应用 74 项内容，并由服务密钥签署 74 项机器结果和在线 hash；
|
||
- 继续验证 1 个起草＋8 个审查运行时 Prompt 快照以及 RC-06 UAT。
|
||
|
||
系统侧使用 `yuqei-infra/scripts/Launch-ReleaseAuthority.ps1` 调用
|
||
`rc06-release-trust-bootstrap.py`。该入口与审核人入口分离，默认非交互：
|
||
|
||
- `initialize` 一次性生成互不相同的 RC-06 approval root、recovery root 和
|
||
apply-service 三把 Ed25519 技术密钥；私钥只以 Windows CurrentUser DPAPI
|
||
密文保存在源码树外，并继承仅当前账户与 SYSTEM 可访问的 DACL；
|
||
- `build-recovery-keyrings` 使用 recovery root 分别签发 first-release 与
|
||
rollback 两种 schema/key-id 的 keyring；两者可共享 recovery root，但不能
|
||
混用 schema、root key id 或签名 payload；
|
||
- `pin-source` 默认只预览，显式 `--apply` 才会以严格匹配和事务回退方式固定
|
||
三类公钥 SHA、两个 recovery keyring payload SHA 和精确 epoch；不写入私钥；
|
||
- `sign-rc06-keyring` 只在冻结 manifest 形成后签发绑定精确 manifest 原始 SHA
|
||
的候选专属 keyring；
|
||
- `sign-apply-payloads` 只签署已经包含 74 项在线 hash、且可由正式 RC-06
|
||
verifier 完整验证的 canonical apply payload；所有 receipt 先在内存生成并
|
||
逐项自验，再作为禁止覆盖的完整 bundle 原子写出，不调用业务 API；
|
||
- `provision-apply-private-key` 在安全 secret-store 交付适配器完成前保持
|
||
fail-closed，不会导出明文或 DPAPI 私钥。
|
||
|
||
DPAPI 与 DACL 不能抵御已经控制当前 Windows 账户的进程。正式初始化仍只能在
|
||
发布负责人确认的干净受控主机上执行；临时 UAT 主机、源码仓库、聊天、邮件、
|
||
共享盘和构建 artifact 均不得成为技术私钥的保存位置。当前新增工具代码本身不
|
||
表示真实技术密钥、pin、keyring、apply receipt 或发布授权已经形成。
|
||
|
||
## 4. 不得执行的操作
|
||
|
||
- 不得手工编辑 manifest、request、keyring、approval、SHA 或签名 JSON；
|
||
- 不得把 payload SHA 当作 manifest 原始文件 SHA；
|
||
- 不得在候选冻结后修改 pin 或源码；
|
||
- 不得复用审核私钥作为离线根密钥或 apply 服务密钥；
|
||
- 不得把本地初始化、自动测试或一次 RC-06 签名描述为正式政策批准、第三方存证、司法效力证明或公众生产放行。
|
||
|
||
## 5. 运行环境信任边界
|
||
|
||
`-I -S -B`、Python Software Foundation 签名检查和本机 ACL 用于减少错误运行时、环境变量注入、跨账户读取及普通文件漂移；它们不等同于受操作系统保护的代码签名发布程序，也不能抵御已经控制当前 Windows 账户、能够键盘注入或篡改用户可写 Python/密码库的恶意进程。
|
||
|
||
因此，正式初始化和签署必须在发布负责人确认的干净离线 Windows 主机上执行，并在候选证据中记录实际 Python、Python DLL 和 cryptography 完整导入闭包的固定 digest。若要把“当前账户已失陷”纳入防护范围，必须另行交付代码签名 EXE/MSI 并安装到受保护目录；本 CMD/PowerShell/Python 工具不得被描述为具备该防护能力。
|
||
|
||
## 6. 正确顺序
|
||
|
||
`审核密钥初始化 → 固定长期 root/apply pin 与候选精确 epoch → 唯一 commit/tag 冻结 → BUILD → RC05-RUN → manifest 形成 → 系统根签候选专属 keyring 与待审请求 → 陈钰麒一次签署 → 自动验签和 74 项应用证据 → RC06-UAT`
|
||
|
||
若 inbox 没有请求，工具不会生成批准；若存在不同候选的旧过期请求，工具会认证后自动归档；若仍存在多个有效请求，工具必须拒绝猜测。陈钰麒不需要手工配置或删除文件。
|