feat(m190): 产物署名（PE VERSIONINFO）+ 清单 Ed25519 多签名与更新前验签
两件事：让「这是谁发的」在产物与清单上都留下可验证的痕迹。
① PE 版本资源（两个 bin）：`packaging/pe_version.rs` 是唯一口径（CompanyName
「Unlucky Launcher Project」/ ProductName、FileDescription「Unlucky Launcher」/
LegalCopyright「© 2026 … · Apache-2.0」/ 四段式版本号与 Cargo.toml 同源），被
`crates/{cli,app-iced}/build.rs` 各 include 一次；非 windows 目标整段不执行。
判据是读产物字节的 `packaging/check_pe_version.py`（CI 的 Windows 槽位）。
② 清单签名：`manifest.json` 旁边多一份 `manifest.json.sig`（分离签名，签的是清单**原始
字节**），信封是 `{format, signatures:[{alg,key_id,sig,manifest_sha256}]}` —— 多签名数组，
任意一条命中钉住的钥即放行（换钥窗口）。信任锚是 `crates/core/src/update/trust.rs`
里的编译期公钥表（正式表为空 = fail-closed，测试钥只在 cfg(test)/update-test-source 里）。
管线顺序改成「先验签、再解析」：`UpdateSource` 只交原文 + `.sig`，`verified_manifest`
是唯一收口点，`Job::apply` 因此在取包**之前**就拒。新增五类错误分类
（signature_missing / malformed / unknown_key / keyring_empty / invalid ），全部不可重试，
CLI 的 hint 单独说人话。
③ Ed25519 验签自带实现（`update/ed25519/*`，零新依赖）：scope 不含 core 的 Cargo.toml，
用 RFC 8032 §7.1 向量 + 可锻/小阶/非规范编码的拒绝用例钉住；签名侧是
`packaging/sign_manifest.py`（纯 Python 参考实现，零 pip 依赖，`--self-test` 同向量）。
④ 守门：`release-publish.yml` 加签名步（`set +x`，只回显公钥；没 Secret / 钥没钉 / 签不上
一律红 ⇒ 不出 Release）；`release-build.yml` 加 PE 资源读回；`release-guard.yml` 跑两个
脚本的 `--self-test`。密钥纪律与轮换（旧钥签新钥）写在 `packaging/docs/signing.md`。
Cargo.lock：新增 winresource（build-dependency）与 toml 系；toml_datetime 1.1.2→1.1.3 是
toml 1.2.1 的硬要求（`cargo update --precise 1.1.2` 已实测被拒）。
This commit is contained in:
AskaEth committed
1 parent
44a0c87a11
commit
b7d9b99e12
34 files changed
+2885
-104
No files matched your search
@@ -0,0 +1,137 @@
|
||||
# 产物签名与更新验签（M190）
|
||||
|
||||
本文件是**发布侧手册**：私钥从哪来、怎么用、怎么轮换、哪一步失败必须让发布变红。
|
||||
用户面的说明（README 里「为什么第一个包要手动下」那类话）不在本文件范围。
|
||||
|
||||
## 0. 先说清这件事**不**解决什么
|
||||
|
||||
| 有 / 没有 | 状态 |
|
||||
|---|---|
|
||||
| 更新器验「清单是不是我们发的」 | **有**（Ed25519 清单签名 + 二进制里钉住的公钥） |
|
||||
| Windows 上「未知发布者」提示消失 | **没有**。项目自有签名与 Authenticode 是两件事 |
|
||||
| SmartScreen 信誉 | **没有**。只有买了 OV/EV 证书并真签名才可能逐步积累 |
|
||||
|
||||
> 一句话：**项目自有签名保护的是自更新这条链，不是 Windows 的信任判断。** 用户双击 exe 时看到的
|
||||
> 「未知发布者」来自 SmartScreen，与本文件的方案无关；买证书是另一条线（见 M190 报告里的
|
||||
> 「后续要用户拍板的两件事」）。
|
||||
|
||||
## 1. 威胁模型（为什么要签名）
|
||||
|
||||
清单里的 `sha256` 只保证「包体与清单对得上」。**能改 Release 的人可以同时改包和摘要**，所以摘要
|
||||
本身不是信任根。签名的对象因此是**清单文件的原始字节**：改了任意一个字段（哪怕只改版本号里一个数字），
|
||||
签名立刻对不上。
|
||||
|
||||
```
|
||||
发布侧 用户机器
|
||||
------ --------
|
||||
manifest.json（字节）──签名──> manifest.json.sig
|
||||
│ │
|
||||
└── 挂到同一个 Release ─────────────┤
|
||||
├─ 取清单 + .sig
|
||||
├─ 用**编译进二进制**的公钥验签（trust.rs）
|
||||
├─ 过了 → 再解析、再比 sha256、再装
|
||||
└─ 不过 → 五类签名错误，**什么都不会被安装**
|
||||
```
|
||||
|
||||
## 2. 信任根在哪：`crates/core/src/update/trust.rs`
|
||||
|
||||
* 公钥是**编译期常量数组**（`PRODUCTION`），不是用户机器上的文件 —— 没有环境变量、没有设置键、
|
||||
没有「清单旁边的 keyring.json」这类运行期口子（`tests/signature_cases.rs::no_runtime_keyring_override`
|
||||
守着这条）。
|
||||
* 是**数组**而不是一把：换签名方时新旧钥可以并存（见 §5）。
|
||||
* `key_id` 只是查表标签，**判据永远是公钥字节**：把 `key_id` 伪造成钉住的那个也过不了
|
||||
（`key_id_spoofing_does_not_help`）。
|
||||
|
||||
### 空表 = fail-closed
|
||||
|
||||
正式表当前**是空的**：私钥只能来自仓库 Secret，任何代码仓库都不该自己生成并落盘私钥。
|
||||
空表的效果是「任何正式构建都拒装任何清单」，同时 `--check-pinned-keyring` 让发布流水线当场红。
|
||||
**这是有意的**：宁可不出 Release，也不出未签名的 Release。
|
||||
|
||||
## 3. 一次性录入（只做一次）
|
||||
|
||||
```bash
|
||||
# ① 生成：打印一段 Secret JSON + 一行可以直接贴进 trust.rs 的 PinnedKey
|
||||
python3 packaging/sign_manifest.py --generate-key --key-id ull-release-2026a
|
||||
```
|
||||
|
||||
* 打印出来的 **第一行 JSON**（含 `seed_hex`）= 私钥，**只**贴进仓库 Secret：
|
||||
Settings → Secrets and variables → Actions → New repository secret，名字
|
||||
**`ULL_MANIFEST_SIGNING_KEY`**。
|
||||
* 打印出来的 **`PinnedKey { … }` 那一行**贴进 `crates/core/src/update/trust.rs` 的
|
||||
`>>> PINNED-KEYS >>>` 与 `<<< PINNED-KEYS <<<` 标记之间（标记本身不要动，脚本按它解析）。
|
||||
* 提交这次改动（公钥进 git 是对的：它是信任锚，本来就该公开可审计）。
|
||||
|
||||
### 私钥纪律（违反任何一条都算事故）
|
||||
|
||||
1. **只**存在于仓库 Secret `ULL_MANIFEST_SIGNING_KEY`。本地需要签测试产物时，走 `--key <文件>`
|
||||
并把那个文件放在**仓库外**（gitignore 不保险，别放仓库里）。
|
||||
2. **不得**出现在日志、产物、提交、issue、聊天记录里。CI 里任何 `echo`/`cat`/`set -x` 都不许碰到它
|
||||
（工作流里的签名步骤显式 `set +x` 且只回显**公钥**）。
|
||||
3. 一旦怀疑泄露：立即按 §5 轮换，并在下一个 Release 的说明里点名旧 `key_id` 作废。
|
||||
4. 私钥文件/Secret 的备份不归仓库管；**丢了 = 旧钥作废**，用户机器上的旧二进制只能靠
|
||||
「先手动装一次新版本」恢复（`trust.rs` 里的旧条目那时才可以删）。
|
||||
|
||||
## 4. 发布时发生什么（`.github/workflows/release-publish.yml`）
|
||||
|
||||
在 `manifest.json` 生成之后、`gh release create/upload` 之前，多了一步：
|
||||
|
||||
```bash
|
||||
python3 packaging/sign_manifest.py --self-test # RFC 8032 向量自检
|
||||
python3 packaging/sign_manifest.py --check-pinned-keyring # 密钥 ↔ trust.rs 必须对得上
|
||||
python3 packaging/sign_manifest.py --sign dist/manifest.json # 产出 dist/manifest.json.sig
|
||||
python3 packaging/sign_manifest.py --verify dist/manifest.json dist/manifest.json.sig --public-key <keyring 里的那把>
|
||||
```
|
||||
|
||||
四条命令任何一条非零退出 ⇒ **这一步红 ⇒ 整个 Release job 红 ⇒ 本次不出 Release**。常见红法：
|
||||
|
||||
| 现象 | 原因 | 怎么补 |
|
||||
|---|---|---|
|
||||
| `没有签名密钥` | Secret `ULL_MANIFEST_SIGNING_KEY` 没配 / 名字拼错 | 按 §3 录入 |
|
||||
| `信任表是空的` | `trust.rs` 里还没钉任何公钥 | 把 §3 打印的 `PinnedKey` 那行贴进标记之间 |
|
||||
| `签名钥（…）不在信任表里` | Secret 与 `trust.rs` 是**两把不同的钥** | 用同一把钥重跑 §3，或回滚 `trust.rs` 的改动 |
|
||||
| `签出来的签名自己验不过` | 实现/环境异常 | 不要发布；把 `--self-test` 输出贴进 issue |
|
||||
|
||||
`dist/manifest.json.sig` 与 `dist/manifest.json` 一起作为 Release 资产上传（`assets=(...)` 那一行）。
|
||||
|
||||
## 5. 轮换（换钥 / 旧钥泄露 / 接托管签名）
|
||||
|
||||
**纪律：旧钥签新钥。** 不允许在没有旧钥签名的情况下替换信任表 —— 那等于让「能改仓库的人」变成
|
||||
「能改信任根的人」。
|
||||
|
||||
1. 生成新钥（§3），得到 `key_id = ull-release-2027a`。
|
||||
2. `trust.rs` 里**保留**旧条目、**追加**新条目（数组顺序无关；`key_id` 不能重名）。
|
||||
3. 在一次发布里，让清单**同时带两把钥的签名**（两条 `signatures`，客户端「任意一条通过即放行」）：
|
||||
用旧钥签一次、新钥签一次，把两个信封的 `signatures` 数组拼起来放进 `manifest.json.sig`。
|
||||
这一步让「装着旧二进制的用户」和「装着新二进制的用户」都过得去。
|
||||
4. 之后至少**一个完整发布周期**保持双签名，再观察下载/更新失败率。
|
||||
5. 确认新钥已被广泛接受后，用新钥单独签发下一次清单，并从 `trust.rs` 删掉旧条目
|
||||
（删条目的那个版本必须**只**由新钥签）。
|
||||
6. changelog 里点名：新增/作废的 `key_id` 与公钥指纹。
|
||||
|
||||
托管签名（例如 SignPath Foundation）作为**后续可替换路径**：它的产物签名由 CI 侧调用其服务完成，
|
||||
`trust.rs` 的数组形状不用变（多一条 `PinnedKey` 即可）；清单签名这一层保持本项目自有钥不动。
|
||||
**不允许**为了接托管签名把判据改成「只认证书」。
|
||||
|
||||
## 6. 三条守门（都能单独变红）
|
||||
|
||||
| 守门 | 脚本 / 用例 | 变红意味着 |
|
||||
|---|---|---|
|
||||
| 版本资源真的在产物里 | `packaging/check_pe_version.py <exe> --expect-version <版本>` | 读回产物字节找不到 `VS_VERSIONINFO` / 字段值不对（构建日志绿也没用） |
|
||||
| 篡改清单 ⇒ 验签失败且不安装 | `cargo test -p unlucky-core --lib update::tests::signature_cases` | 改字段/只改签名/漏签名/陌生钥 任一仍能装 |
|
||||
| 签名失败阻断发布 | `release-publish.yml` 的签名步 + `--check-pinned-keyring` | 没钥/钥没钉/钥不匹配时仍发出 Release |
|
||||
|
||||
另外 CI 的构建槽位会跑 `check_pe_version.py`（`release-build.yml`）：Windows 槽位上直接读
|
||||
`target/release/unlucky-launcher-iced.exe` 与 `ull.exe` 的字节，断言 `CompanyName` 等字符串在。
|
||||
|
||||
## 7. 本地自测（不需要私钥）
|
||||
|
||||
```bash
|
||||
python3 packaging/sign_manifest.py --self-test # RFC 8032 向量 + 标记解析
|
||||
python3 packaging/check_pe_version.py --self-test # 口径表与 pe_version.rs 对拍
|
||||
cargo test -p unlucky-core --lib update::tests::signature_cases
|
||||
cargo test -p unlucky-core --lib update::tests::ed25519_cases
|
||||
```
|
||||
|
||||
带 `update-test-source` 的验收构建里另有一把**公开的测试钥**（种子写在测试夹具里）：它只用于
|
||||
「本地目录源 + 真二进制」的端到端验收，**不在**正式信任表里，签不出任何正式版本能装的清单。
|
||||
Reference in new issue
Block a user