8 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	af82658d08	fix(core,app-iced): M308 Linux/macOS 的 .tar.gz 真的能自替换 + 重试按 retryable 分流 + 三处文档纠偏 ... M307 盘查抓到的一条真缺陷 + 两处交互/文档不一致，本条只修它们，不重做通道： ① Linux/macOS 自更新的真缺陷（选 A：真做） `job::self_replaceable` 只认裸 exe，而发布矩阵里那两平台的启动器是 `.tar.gz`（清单记作 `portable-zip`）⇒ 查得到更新、按钮画得出来、点下去必失败。新增 `core::update::unpack`： **归档字节过完长度/摘要双检之后**，从归档里取出启动器本体（tar 头 mode 有可执行位 / `.exe` 名字的唯一普通文件），再交给原有的 `install_staged`（原子替换 + 回滚一字未改）。 零新依赖（flate2/tar 早就是 core 的依赖，`core::game::java` 解 Temurin 用同一套）。 三条具名错误：`LauncherMissing` / `LauncherNotExecutable`（魔数与 target 不符）/ `LauncherSizeMismatch`（0 字节 / 超上限 / 与头声明不符）；zip 容器**明确拒绝**（没有可靠的 「哪个条目可执行」判据，不猜）。`target.rs` 的 `PackageFormat` 文档改成与判据逐字一致。 ② 重试按钮按 `retryable` 分流 验签类（`is_retryable == false`）不画「重试」，正文换成新 key `UpdateBannerFailedFinal` （「这次更新已被拒绝（重试没用）：{reason}」）。文案抽到 `pages/update/failure.rs` （`pages/update.rs` 的红线），判据落在**真 Widget 树**上（探针 tag + 递归计数）。 ③ 三处文档纠偏 + 同一条谎话的其它落点（都在 scope 内） `trust.rs`（正式表已有 `ull-release`，commit 68362e5）、`check_signing_ready.py` 自述、 `target.rs`；顺带 `packaging/README.md`、`docs/{signing,signing-runbook}.md`、 `check_test_key_off.py`；新文档 `docs/update-trust-anchor.md` 记「M254 审计的『正式表为空』 已作废」。 判据：core 新增 `unpack_cases`（Linux tar.gz / macOS tar.gz 走完整条链 + 五种拒绝）、 `job_cases` 的形态表改成两种；app-iced 两条真 Widget 树用例（按钮在 / 不在）+ 一条取词入口用例 + 一条源码守卫。i18n 加一条 key 并**重出金表**（`Key::ALL` 853 行，新行落在 index 834）。	2026-11-13 23:38:17 +08:00
AskaEth	00965e19d2	fix(core): trust.rs 的 PinnedKey 交回 rustfmt 排版（多行字段）+ 自测锁住多行解析 ... v0.2.4 推 main 后 CI 的 fmt job 红：cargo fmt --all --check 退出码 1，唯一 diff 在 crates/core/src/update/trust.rs:60 —— PRODUCTION 里那条 PinnedKey 被写成单行。 * trust.rs：由 `cargo fmt --all` 直接生成（不是手写对齐）。git diff 只有这一处； 两个 PINNED-KEYS 标记行的字形与行位置未动；public_key_hex 与 HEAD 逐字比对 identical。 * sign_manifest.py --self-test：补一条多行（rustfmt）形态样例的解析断言。解析器本身无需改 （KID_RE 字段之间是 \s*，本来就跨行），但旧自测只喂单行样例 —— 变异重放（换成单行整行正则） 时旧自测全绿、新断言红，正是这次事故的形状。 验证（真实退出码）：cargo fmt --all --check = 0；python packaging/sign_manifest.py --check-pinned-keyring --key <私钥路径> = 0；signing_ready_selftest.py = 0； signing_ready_wiring_selftest.py = 0；sign_manifest.py --self-test = 0； cargo test -p unlucky-core --lib update = 0（114 passed / 0 failed）。	2026-11-11 22:01:26 +08:00
AskaEth	68362e5408	feat(core): 钉入生产签名公钥（key_id ull-release）+ .gitignore 防私钥入库	2026-11-11 21:35:10 +08:00
AskaEth	50d13d26ab	fix(m201): 测试钥改由 #[cfg] 编译期剔除，无测试档产物里不再留那段字节 ... `keyring()` 原先用 `cfg!(...)` 判断要不要并入测试钥 —— 那是「运行期值为假的分支」， `TEST_ONLY` 的字节照编进产物（实测：无 feature 的 dev / release 两档 core rlib 里， 测试公钥十六进制与 key_id 都能 grep 到）。 * `TEST_ONLY` 拆成两条同名 const：`#[cfg(any(test, feature = "update-test-source", feature = "update-test-key"))]` 的真条目 + `#[cfg(not(any(...)))]` 的空表； `keyring()` 删掉 `cfg!` 判断，改成无条件 `extend_from_slice(TEST_ONLY)`（空表那档等于 什么都没并，`mut` 两档都有用武之地，不需要 `unused_mut` 口子）。 * 文档把 M199 降级掉的那句强断言改回真话，并贴出六行实测读数（dev / release 均 0 命中， 带 `--features update-test-key` 的对照臂 2 命中）。 * 明确划界：读数只到 rlib 为止；最终 exe 经 `lto = "fat"` + `strip = "symbols"` 之后是否 仍有那段字节**未验**。 验收：cargo fmt --all --check → 0；cargo clippy --workspace --all-targets -- -D warnings → 0； cargo test -p unlucky-presenter → 311 passed / 0 failed（1 ignored）； cargo test --workspace --all-targets → 0。	2026-11-09 08:19:04 +08:00
AskaEth	540b82e197	fix(m200-r1): 文档降到实测能撑的程度 + 守门收紧 core 声明内容（复审 P2-1 / P3-1） ... 复审 reviewer-presenterfix-r1 的 fix-then-merge 两条，逐条落地。 P2-1(a)「两档」措辞被本次提交自己作废 ⇒ 三处全改成三档： * `crates/core/src/update/trust.rs` 模块文档（读者最先看到的那句，上次漏了） * `crates/core/src/update/tests/support_sign.rs` 模块文档 + `TEST_SIGNING_SEED` 的文档 P2-1(b)「三者都进不了发布产物」被复证实测证伪（`cfg!()` 是运行时假分支，不是 `#[cfg]` 编译期剔除；无 feature 的 dev 与 --release 两档 core rlib 里公钥十六进制与 `test-only-key` 都在） ⇒ 降级到事实能撑的断言：「不会被 `keyring()` 并进信任表，正式构建永远不认这把测试钥」， 并明写「字节仍编在产物里」「字节级不在产物里未证、也未声称」「换 `#[cfg]` 是另一条结构性改动」。 没有换成 `#[cfg]`（那是复审建议另开的 mission）。 P3-1 守门对 core「自己的声明」只认形状 ⇒ 收紧为只许空数组： `DECLARATION` 从 `^\s*update-test-key\s*=\s*\[` 改成 `^\s*update-test-key\s*=\s*\[\s*\]\s*$`， 并加一条自检向量（core 声明里偷偷带子 feature ⇒ 必须红）。`--self-test` 从 6 条变 7 条 （5 红 / 2 绿）+ 基线，`packaging/README.md` 的计数同步。 ⚠ 一个自己踩出来的坑，已被既有守门抓住：收紧时我先在 `check_test_key_off.py` 里把那条更宽的 测试通道 feature 写成**字面量**（自检向量 + 文档表格），`check_test_source_off.py` 立刻红 （`packaging/**` 按字面扫，这次提交前它一直是绿的）。改法照该文件自己的声明办——用 `OTHER_FEATURE = "-".join(("update", "test", "source"))` 拼出来，源码里字面量为 0， 自检向量仍然构造出完整字符串并必须判红。 验证（均在最终树上）：`cargo test --workspace --all-targets` 0、`cargo fmt --all --check` 0、 `check_test_key_off.py --self-test` 0（7 向量）/ 正式扫描 0、`check_test_source_off.py` 0、 `check_workflows_yaml.py` 0。	2026-11-09 07:56:33 +08:00
AskaEth	528f5706a0	docs(m200): 补 update-test-key 的两处文档一致性（cherry-pick 之外） ... `80b291c` 原样落盘（与本提交前一个 commit 逐字节相同），这里只补两处**文档一致性**， 不改任何判据、不改任何 feature 行为： 1. `crates/core/src/update/trust.rs`：`TEST_ONLY` 的文档注释还写着「**只**在 `cfg(test)` 与 `update-test-source` 构建里存在」——同一文件里 `keyring()` 新增的表已经把三档（`cfg(test)` / `update-test-source` / `update-test-key`）讲清了，上面这句变成了自相矛盾的旧口径。改成三档， 指向 `keyring()` 的说明。 2. `packaging/README.md` §12「文件清单」：新守门 `packaging/check_test_key_off.py` 已接进 `release-guard.yml`，但清单表里没有它（同类守门 `check_test_source_off.py` 在表里），补一行。 验证：`cargo test --workspace --all-targets` exit 0（311 passed）、`cargo clippy --workspace --all-targets -- -D warnings` exit 0、`cargo fmt --all --check` exit 0、 `packaging/check_test_key_off.py`（自检 + 正式扫描）exit 0、`packaging/check_workflows_yaml.py` exit 0。	2026-11-09 07:56:33 +08:00
AskaEth	19cc5c7950	fix(m190): presenter 更新链路用例补上清单签名（6 条既有测试回绿）+ 测试公钥守门 ... 背景：M190 把「验签」做成了强制且唯一收口（`source::verified_manifest`，先验签再解析），而 `crates/presenter` 的更新链路用例只写 `manifest.json`、不写 `.sig` —— 它们写在验签之前，所以在 dev 上红成 6 条 `signature_missing`。真发布本来就必须带 `.sig`，所以修的是**夹具**，不是判据： 没有放宽任何断言、没有在测试里关掉验签、没有把 `available=true` 改成「接受 Failed」。 夹具（`crates/presenter/src/host/update_tests.rs`）： * `write_manifest()` 把清单**连签名**成对落盘（`dist/stable.json` + `dist/stable.json.sig`）， `dir_source()` 改走它；三处直接写清单的用例（坏清单 / 空清单 / 缺本平台产物）也改走它。 * 签名用 `TEST_SIGNING_SEED` + `key_id = test-only-key`，信封形状与 core 的 `tests/support_sign.rs` **同源**（文件头写明「改一处要改两处」；presenter 不依赖 core 的 `#[cfg(test)]` 资产，也没把测试资产导出成生产 API）。 为了让这把**公开**测试公钥在 presenter 的测试构建里被认得： * core 新增 feature `update-test-key`（**只**把 `trust::TEST_ONLY` 并进信任表，不开任何数据源开关）； * 只有 `crates/presenter` 的 `[dev-dependencies]` 打开它（库/发布构建拿不到）；锁里只多 `ed25519-dalek` 这一行（presenter 的 dev-dep，包已在锁里，无新包、无版本变动）； * 新守门 `packaging/check_test_key_off.py`（238 行，带 6 条变异自检）接进 `release-guard.yml`： core 的 `Cargo.toml` 只许自己的声明、presenter 只许 `[dev-dependencies]` 段内，其余（workflow / packaging 脚本 / 根 Cargo.toml / cargo 配置）出现即红 —— 这把钥进发布构建就等于「谁都能签出官方更新」。 * 没有用 `debug_assertions`/`cfg(test)` 旁路：那会让「测试构建的信任表和发布构建不同」变成一句注释， 而不是一条门禁。	2026-11-09 07:56:32 +08:00
AskaEth	b7d9b99e12	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` 已实测被拒）。	2026-11-09 01:59:05 +08:00