AskaEth
918d826645
四条 P1 + 四条 P2 一并处置（不变的是判据，变的是「谁在承重」）。
P1-1 `.github/workflows/release-build.yml` 的 sed 替换串是裸 0x01（本意 `\1`）：GitHub 解析该文件会
失败 ⇒ 整个 run 起不来；即便容忍，版本号也会被求值成单字节，PE 判据报「与 Cargo.toml 不同源？」把
排障引向错方向。修成字面 `\1`，并新增 `packaging/check_workflows_yaml.py`（真 YAML 解析器 parse
全部 workflow + 裸 C0 控制字符字节判据；带 --self-test 注入 0x01/坏结构断言必红），接进
`release-guard.yml` 两步。文本扫描型守卫看不见这类字节，这道门禁专门挡它。
P1-2 `release-publish.yml` 没在 `on.workflow_call.secrets` 里声明 `ULL_MANIFEST_SIGNING_KEY`，调用方
却传了：可复用工作流只拿得到自己声明过的 secret ⇒ 用户配好钥也会在签名步红，而错误文案反过来指控
Secret 没配。补声明（required: false，fail-closed 由步内 ::error:: + exit 1 承担，同
ULL_MSA_CLIENT_ID 的模式）。
P1-3 两个测试支撑文件越过 400 行守卫：签名夹具拆到 `tests/support_sign.rs`（support.rs 458→392），
CLI e2e 的签名部分拆到 `support/update_e2e_sign.rs`（update_e2e.rs 406→348）。纯搬家。
P2-2 「唯一收口点」改成结构事实：从 `UpdateSource` 删掉 `fetch_manifest` 默认实现，调用方只能拿
`verified_manifest(&source, channel)`（源只交原文，想绕过验签就得自己重写解析与渠道判据）。
P2-3 文档写的第 ④ 条命令补进流水线：`sign_manifest.py --verify-pinned` 用 trust.rs 里钉住的公钥
回验刚落盘的 .sig（不碰私钥），发布侧因此验证的是「客户端的判据」而不是「签名脚本的自我声明」。
P2-4 随自写实现一起删除（`Fe` 的错误 PartialEq 不再存在）。
P2-5 app-iced/build.rs 注释里那个 windows_subsystem 属性本分支不存在（M196 才有），改为说明
「本文件只写版本资源，子系统由 rustc 属性决定，check_pe_version.py 会把 subsystem 打出来」。
P2-6 坏清单不再带 error.path 是有意降级（来源 id 在 message 里），保持。
裁定项：自写 Ed25519 换成 `ed25519-dalek::verify_strict`（信任锚不许自写密码学；此刻信任表还是空表，
零兼容负担）。删除 `update/ed25519/{field,group,mod}.rs`（含只服务它们的单测），新 `update/ed25519.rs`
只剩一个薄封装；拒绝类用例（可锻 S+L / 小阶公钥 / 非规范 R / 空签名 / 未知 key）**一条没删**，
改成钉 dalek 的 strict 语义——实测 dalek 对全部五类的结论与旧实现一致（非规范 R 的拒绝理由不同：
dalek 走「小阶点」而非「编码非规范」，用例注释里写明）。签名侧留在 `packaging/ed25519_ref.py`
（纯 Python、零 pip 依赖），`--self-test` 用 RFC 8032 同一组向量钉两边。
70 lines
3.2 KiB
Rust
70 lines
3.2 KiB
Rust
//! 更新 e2e 夹具的**签名**部分（M190）：用 `packaging/sign_manifest.py` 给清单签 `.sig`。
|
|
//!
|
|
//! 为什么单独一个文件：`support/update_e2e.rs` 已经贴着全仓 400 行红线（M190 r1 复审 P1-3），
|
|
//! 而签名这一摊只被 `Fixture::publish` 用到。搬出来是纯搬家，语义未改。
|
|
//!
|
|
//! 为什么走**真脚本**而不是在测试里再写一份签名：这样这套端到端用例同时是「发布侧签名脚本 ⇒
|
|
//! 真二进制验签」的跨实现证据（Python 签、Rust 验）。脚本零第三方依赖，CI runner 与开发机都自带
|
|
//! python3/python；找不到 python 时这套用例**直接红**（不静默跳过——跳过等于这条链没有证据）。
|
|
|
|
use std::path::Path;
|
|
|
|
/// 测试签名钥的种子（**公开**：只对 `update-test-source` 构建有意义，正式信任表里没有这把钥，
|
|
/// 见 `crates/core/src/update/trust.rs::TEST_ONLY`）。
|
|
const TEST_KEY_SEED: &str = "ull-m190-test-key-seed-000000001";
|
|
/// 测试钥的 `key_id`（与 `trust.rs::TEST_ONLY` 一致）。
|
|
const TEST_KEY_ID: &str = "test-only-key";
|
|
|
|
/// 用 `packaging/sign_manifest.py` 给刚落盘的清单签一份 `.sig`（M190）。
|
|
///
|
|
/// 为什么走**真脚本**而不是在测试里再写一份签名：这样这套端到端用例同时是「发布侧签名脚本 ⇒
|
|
/// 真二进制验签」的跨实现证据（Python 签、Rust 验）。脚本零第三方依赖，CI runner 与开发机都自带
|
|
/// python3/python；找不到 python 时这套用例**直接红**（不静默跳过——跳过等于这条链没有证据）。
|
|
pub fn write_signature(manifest_path: &Path) {
|
|
let script = Path::new(env!("CARGO_MANIFEST_DIR")).join("../../packaging/sign_manifest.py");
|
|
assert!(script.is_file(), "找不到签名脚本：{}", script.display());
|
|
let seed_hex: String = TEST_KEY_SEED
|
|
.as_bytes()
|
|
.iter()
|
|
.map(|byte| format!("{byte:02x}"))
|
|
.collect();
|
|
let secret = format!(r#"{{"key_id":"{TEST_KEY_ID}","seed_hex":"{seed_hex}"}}"#);
|
|
let mut command = None;
|
|
for candidate in ["python3", "python"] {
|
|
if std::process::Command::new(candidate)
|
|
.arg("--version")
|
|
.output()
|
|
.is_ok_and(|output| output.status.success())
|
|
{
|
|
command = Some(candidate);
|
|
break;
|
|
}
|
|
}
|
|
let python = command.unwrap_or_else(|| panic!("这套用例需要 python3/python 跑 {script:?}"));
|
|
let output = std::process::Command::new(python)
|
|
.arg(&script)
|
|
.arg("--sign")
|
|
.arg(manifest_path)
|
|
.env("ULL_MANIFEST_SIGNING_KEY", &secret)
|
|
.output()
|
|
.expect("跑签名脚本");
|
|
assert!(
|
|
output.status.success(),
|
|
"签名脚本失败：stdout={} stderr={}",
|
|
String::from_utf8_lossy(&output.stdout),
|
|
String::from_utf8_lossy(&output.stderr)
|
|
);
|
|
assert!(
|
|
manifest_path
|
|
.with_file_name(format!(
|
|
"{}.sig",
|
|
manifest_path
|
|
.file_name()
|
|
.map(|name| name.to_string_lossy().into_owned())
|
|
.unwrap_or_default()
|
|
))
|
|
.is_file(),
|
|
"签名脚本没产出 .sig"
|
|
);
|
|
}
|