From 06fcbb8a51e54f441501a11602c62f597c4d7ecd Mon Sep 17 00:00:00 2001 From: AskaEth Date: Mon, 9 Nov 2026 09:32:54 +0800 Subject: [PATCH] =?UTF-8?q?docs(packaging):=20=E4=BF=AE=E6=8E=89=E4=B8=A4?= =?UTF-8?q?=E4=B8=AA=20=C2=A714=20=E6=92=9E=E5=8F=B7=EF=BC=88M190=20?= =?UTF-8?q?=E8=AE=A9=E4=BD=8D=E5=88=B0=20=C2=A716=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 台账 §10 第 5 条：packaging/README.md 里 §14 被 M169（更新链路测试通道）与 M190（产物署名与 清单签名）各用了一次。 判据（谁后插进来谁让位）：§14 与 §15 都被仓库里的引用钉着——packaging/check_test_source_off.py 引 §14（M169），.github/workflows/release-build.yml 与 crates/app-iced/src/platform/win32/console.rs 引 §15（M196）；这两处引用都在本 mission 的 scope 外。所以 M169 保持 §14、M196 保持 §15， M190 那一节整段后移到文末编 §16，内容一字未改，只改编号与位置（新增一段「编号来历」说明为什么 它让位）。全文 §11/§12/§13/§14/§15/§16 各一次，无重复。 --- packaging/README.md | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/packaging/README.md b/packaging/README.md index 47c2ec6..1360eec 100644 --- a/packaging/README.md +++ b/packaging/README.md @@ -149,20 +149,6 @@ Git Bash 下会静默落进 Docker VM（脚本内部用 `cygpath -m` 归一） `portable-exe`；Linux/macOS 的真实产物是 `.tar.gz` + `portable-zip`，在本模块会被直接拒）。 **不验**真 GitHub 下载、GUI 点击与重启替换（需人工）。 -## 14. 产物署名与清单签名（M190） - -这一节只放「去哪看」的三句话，手册本体在 **`packaging/docs/signing.md`**： - -- **PE 版本资源**（Windows「属性 → 详细信息」里的发布者/产品/版权/四段式版本）：口径唯一来源 - `packaging/pe_version.rs`，被 `crates/cli/build.rs` 与 `crates/app-iced/build.rs` 各 `include!` 一次； - 判据是**读产物字节**的 `packaging/check_pe_version.py`（CI：`release-build.yml` 的 Windows 槽位）。 -- **清单签名**：`manifest.json.sig` 与 `manifest.json` 并列上传，是分离的 Ed25519 签名文件（签的是清单 - 的**原始字节**，不是某个规范化后的 JSON）。信任锚是 `crates/core/src/update/trust.rs` 里的 - **编译期公钥数组**（keyring）；源里没有 `.sig`、钥不在表里、签名对不上，一律 `signature_*` 分类拒装， - **不可重试**。签名脚本 `packaging/sign_manifest.py`（零第三方依赖，`--self-test` 跑 RFC 8032 向量）。 -- **不得混淆**：项目自有签名解决的是「更新器怎么判断这份清单是不是我们发的」，**不解决 SmartScreen** - ——用户双击 exe 时看到的「未知发布者」要等 Authenticode 证书，那是另一条线。 - ## 15. 产物 PE 子系统（M196：GUI 必须 `WINDOWS_GUI`=2） 群友 2026-11-08 实测发布构建「运行时会带一个控制台窗口在底下」。根因：产物 PE 头的 `Subsystem` 仍是 @@ -203,3 +189,22 @@ CUI(3)，`grep -rn windows_subsystem crates/` 当时零命中。同一个修复 `instances list` / `--help` 全 0（`logs list` 是 1，但重定向跑同一条也是 1 ⇒ 用户错误，不是写失败）。 想让这种情形有专属退出码/文案，得在 CLI 侧显式判一次能力（`platform::win32::console` 的 `output_visible()` 就是现成判据），那在 `crates/cli/**`、不在 M196 的 scope 内——这里只如实记录形态。 + +## 16. 产物署名与清单签名（M190） + +**编号来历（M203）**：本节原先也编作 §14，与 §14「更新链路的测试通道（M169）」撞号。撞号按「谁后插进来谁让位」 +处理：M169 的 §14 与 M196 的 §15 都被仓库里的引用钉着（`packaging/check_test_source_off.py` 引 §14； +`.github/workflows/release-build.yml` 与 `crates/app-iced/src/platform/win32/console.rs` 引 §15）， +所以本节后移编 §16 并放到文末——**内容一字未改，只改了编号和位置**。 + +这一节只放「去哪看」的三句话，手册本体在 **`packaging/docs/signing.md`**： + +- **PE 版本资源**（Windows「属性 → 详细信息」里的发布者/产品/版权/四段式版本）：口径唯一来源 + `packaging/pe_version.rs`，被 `crates/cli/build.rs` 与 `crates/app-iced/build.rs` 各 `include!` 一次； + 判据是**读产物字节**的 `packaging/check_pe_version.py`（CI：`release-build.yml` 的 Windows 槽位）。 +- **清单签名**：`manifest.json.sig` 与 `manifest.json` 并列上传，是分离的 Ed25519 签名文件（签的是清单 + 的**原始字节**，不是某个规范化后的 JSON）。信任锚是 `crates/core/src/update/trust.rs` 里的 + **编译期公钥数组**（keyring）；源里没有 `.sig`、钥不在表里、签名对不上，一律 `signature_*` 分类拒装， + **不可重试**。签名脚本 `packaging/sign_manifest.py`（零第三方依赖，`--self-test` 跑 RFC 8032 向量）。 +- **不得混淆**：项目自有签名解决的是「更新器怎么判断这份清单是不是我们发的」，**不解决 SmartScreen** + ——用户双击 exe 时看到的「未知发布者」要等 Authenticode 证书，那是另一条线。