AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
863 Commits 3 Branches 7 Tags
06712ff6e9844a7ef545b77d1ede71098fc0d0b1
Commit Graph
5 Commits
Author SHA1 Message Date
AskaEth 06712ff6e9 fix(core,docs): M308 r1 —— 读表工具写错（又一句「文档比代码多」）+ .exe 名字判据空转 + adopt 之后的取值器文档 
p2-1 文档：`--check-pinned-keyring` **要私钥**（`do_check_pinned(args.key)`），语义是「Secret 里那把
钥是否已钉住」这条发布前门禁，不是读表工具。`docs/update-trust-anchor.md` 的「当场看一眼」与
`signing-runbook.md` §0 那句「现在 --check-pinned-keyring 绿」（与同文件 §:116 自相矛盾）都换成
`check_signing_ready.py` 的 ① 行（真只读，实测打「就绪 —— 标记之间 1 条：ull-release…」）。

p2-2 判据：`is_launcher_candidate` 的 `|| name.ends_with(".exe")` 此前**删掉也不红**（唯一含 `.exe`
的用例同时给了 0o755）。补 `a_windows_exe_without_the_exec_bit_is_still_the_launcher`
（win-x64 + 归档内 `unlucky-launcher.exe` + MZ + **0644** 能装上），删那半条判据即红。

p2-3 文档：`StagedPackage::size()` / `integrity()` 的注释在 `adopt` 之后不再成立（前者是本体的字节数、
后者是**归档**的摘要），改成「这个文件写出来的字节数」/「为它背书的那份摘要」。
 2026-11-14 00:15:13 +08:00
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 66eb912df0 fix(packaging): --generate-key 打印的 PinnedKey 改成 rustfmt 保持的多行形态（M265） 
`--generate-key` 与「信任表是空的」报错里给人粘贴的 `PinnedKey` 原来是单行：
    PinnedKey { key_id: "…", public_key_hex: "<64 hex>" },
这一行有 113+ 字符（即使 key_id 为空），超出 .rustfmt.toml 的 max_width = 100，
所以 `cargo fmt` **必然**把它拆成 4 行 —— 人贴单行 → 下一轮 fmt 改动 → 谁忘了跑 fmt
就把 fmt 红带进 main（T30 那次就是这条路径）。

改的是「打印模板」与文档，不是解析器（KID_RE 的 \s* 本来就吃两种形态）：
- 新增 render_pinned_key()，字段各占一行、元素缩进 4/字段缩进 8、结尾逗号，
  与 trust.rs 里 cargo fmt 生成的形状逐字一致；两条打印路径都走它。
- 提示文案不再暗示「贴完还要 fmt」，改成「贴完直接提交，不用再跑 fmt」。
- docs：signing.md §3 与 signing-runbook.md §2/§4/§8 的「那一行」→「那一段（4 行）」，
  并在 runbook §7 明写这条断言在没装 rustfmt 时的退化边界。
- --self-test 新增形态断言：① 渲染结果 == 4 行期望字面量 ② 形状与 trust.rs 现存条目
  （字段值抹平后逐行）一致 ③ 单行必然超 max_width、多行每行都不超 ④ 贴进标记之间能解析
  ⑤ 有 rustfmt 时在临时副本上真跑一遍，要求粘贴块字节不变（没有则打 note 跳过，不装成验过）。
 2026-11-12 09:26:05 +08:00
AskaEth bc1b09b776 fix(packaging): 播报 workflow 的种子只在 main 注入 + --key 用法错回 2 + 指针修正（M255 r1 P2-1/2/3） 
P2-1（安全）：`signing-status.yml` 原先把生产签名种子注入到 `pull_request` 与任意 ref 的
`workflow_dispatch` 运行里，而 CI 跑的是那个 ref 自己的代码 ⇒ 任何能推分支的人都能把种子搬走
（这把种子能给全量已装客户端签可信清单）。改成：
  - 去掉 `pull_request` 触发；
  - 注入行加 ref 门：`github.ref == 'refs/heads/main' && secrets.… || ''`；
  - 非 main 用 `ULL_SIGNING_KEY_WITHHELD` 说明原因，于是 ② 读「未判定（未注入）」而不是「没配」。
runbook §2 步② 加硬顺序：先合这笔、再录 Secret。

P2-2：`--key` 读不了（不存在 / 是目录 / 非 UTF-8）曾在 main 的 try 之外抛 traceback + rc=1，
与「未就绪」同码；现在统一 rc=2 + 一行说明，并补用例 `key_unreadable`。

P2-3：4 处文案指针修正（`signing-ready.yml` → `signing-status.yml`；§3 → §2 步③；§1–§3 →
§2 步①–③；§4 → §2 步⑤ / §5）。新增两条机检：`section_refs`（输出的 `§N` 必须是 runbook 真实
章节号）与 `signing_ready_wiring_selftest.py`（文档里的 `packaging/…`/`crates/…`/`.github/…`
路径必须真存在），后者另带三处变异重放：去掉 ref 门 / 加回 pull_request / 改坏文档路径 ⇒ 必须红。

顺带修掉 r1 复审指出的两处小问题：`--release-assets` 里只有 `manifest.json.sig` 时的子串假读数
（先剥 `.sig` 再判清单）、③ 那个从不参与判定的 bool 保持原样（无行为影响）。

selftest 拆成两份（400 行红线）：判据本体 + 接线/文案。guards.yml 仍 399 行零改动。
 2026-11-11 20:17:04 +08:00
AskaEth bff48e27fa feat(packaging): 签名就绪度播报 + 操作手册（M255） 
M254 查出 `trust.rs` 的 `PRODUCTION` 表在 PINNED-KEYS 标记之间是空的 ⇒ 任何正式二进制都验不过
任何清单（fail-closed）。工具链早就齐了，缺的是操作步骤与可见性；本条补的就是这两样，不生成钥、
不改 Rust、不碰 release-publish 的判据。

- `packaging/check_signing_ready.py`（只读、零第三方依赖）：三行读数 ① 信任表空不空 ② 环境有没有钥
  （顺手对账「这把钥在不在表里」，种子一个字节都不打印）③ 最近一次发布的 .sig/清单痕迹（取不到写
  「未知」）。退出码 0 就绪 / 1 未就绪（打印 fail-closed 后果 + 一行修复命令）/ 2 用法错。
- `packaging/tests/signing_ready_selftest.py`：判据自测，含**两个方向的变异重放**（退出码永远 0 ⇒
  判据①必须红；永远 1 ⇒ 判据②必须红）与接线判据（没人 uses: 它、没有 error 级注解、就绪度那步恒 exit 0）。
- `packaging/docs/signing-runbook.md`：人类照做的 5 步 + 每步判据 + 11 条已知坑 + 没验的部分（无任何密钥值）。
- `.github/workflows/signing-status.yml`：把三行搬进 job summary 的**播报** workflow。guards.yml 已
  399/400，与 gpu-evidence.yml 同先例另开文件；刻意不声明 workflow_call:，未就绪用 ::warning::、
  就绪度那步恒 exit 0，明确「不应被设为 required」。
- `packaging/README.md` / `packaging/docs/signing.md`：索引与指针。
 2026-11-11 20:05:45 +08:00