xm/yuvuCli
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

安全：node deployment show 明文回显 ALLOCATION_SIGNING_KEY（遮蔽策略不一致） #2

New issue
Closed
opened 2026-09-27 02:04:14 +08:00 by xm · 6 comments
xm commented 2026-09-27 02:04:14 +08:00
Owner
Copy link

现象（2026-09-27 01:4x 实测，NAS 节点）

yuvu node deployment show core -node nas -format json 返回的 resolved_plan.env 共 19 项，其中遮蔽策略不一致：

  • 被正常遮蔽为占位符的（取值长度均为 10，即 <redacted>）：YUVU_CORE_ADAPTER_V3_ARTIFACT_SIGNING_SECRET、YUVU_CORE_ARTIFACT_S3_SECRET_KEY、YUVU_CORE_ARTIFACT_S3_ACCESS_KEY、YUVU_MAA_RPC_TOKEN、YUVU_MAEND_RPC_TOKEN、YUVU_MODEL_GATEWAY_CONTROL_TOKEN_FILE
  • 明文返回的两项：
    • YUVU_MAA_ALLOCATION_SIGNING_KEY（64 字符）
    • YUVU_MAEND_ALLOCATION_SIGNING_KEY（64 字符）

判定依据（不打印取值，只统计特征）：

  • 长度 64，字母 52/58、数字 9/3、其它 3、唯一字符 42/40 → 高熵随机串，不是占位符
  • 两个值互不相同，且与已遮蔽项的占位符长度（10）不同 → 确定是真实密钥而非统一替换串

说明：本条 issue 内不复制任何密钥内容，只给出键名、长度与熵特征。

影响

*_ALLOCATION_SIGNING_KEY 是 Adapter V3 执行目标 allocation 的 HMAC 签名密钥（32–4096 字节，密钥错误时 adapter 侧会以 allocation_signing_key 校验失败拒绝请求）。任何能执行 yuvu node deployment show（或直接调 node 的 deployment 查询 API）的人即可拿到该密钥 → 可伪造 allocation 签名 / 越权占用执行目标。这与平台对 RPC token、S3 密钥的遮蔽力度不一致，属凭据泄漏面。

推测根因

遮蔽是按键名模式白名单做的（覆盖 *_SECRET_KEY / *_RPC_TOKEN / *_TOKEN_FILE 之类），_ALLOCATION_SIGNING_KEY 未落入模式 → 直出明文。

期望

  1. 遮蔽改为默认拒绝：凡键名命中 KEY|SECRET|TOKEN|PASSWORD|CREDENTIAL|ACCESS 一律遮蔽，白名单只放必需的公开项（ADAPTER_PROVIDER_BASE_URL、TZ 等）；
  2. 需要看真值时用显式开关（如 --show-secrets，并要求交互确认），而不是默认输出；
  3. 遮蔽策略集中定义在一处并加单测（新增 *_SIGNING_KEY 类键名即被覆盖）；
  4. 建议在 node/core 侧返回 plan 时就遮蔽（不要依赖 CLI 显示层），否则任何直接调 node API 的客户端都会泄漏。

最小复现

export PATH="/home/zx/yuvu/workspaces/bin:$PATH"; source /tmp/node-env.sh
yuvu node deployment show core -node nas -format json \
 | python3 -c "import sys,json;e=json.load(sys.stdin)['resolved_plan']['env'];print({k:len(str(v)) for k,v in e.items() if 'KEY' in k or 'TOKEN' in k})"
# 预期（修复后）：所有密钥类键名长度一致（占位符），无 64 字符项
# 现状：YUVU_MAA_ALLOCATION_SIGNING_KEY / YUVU_MAEND_ALLOCATION_SIGNING_KEY 为 64

关联

  • yuvuCore#7 / yuvuCore#18（provider base_url pin 与注册路径）
  • 同批：yuvuCli 另开的「node 控制能力缺口」issue
## 现象（2026-09-27 01:4x 实测，NAS 节点） `yuvu node deployment show core -node nas -format json` 返回的 `resolved_plan.env` 共 19 项，其中**遮蔽策略不一致**： - 被正常遮蔽为占位符的（取值长度均为 10，即 `<redacted>`）：`YUVU_CORE_ADAPTER_V3_ARTIFACT_SIGNING_SECRET`、`YUVU_CORE_ARTIFACT_S3_SECRET_KEY`、`YUVU_CORE_ARTIFACT_S3_ACCESS_KEY`、`YUVU_MAA_RPC_TOKEN`、`YUVU_MAEND_RPC_TOKEN`、`YUVU_MODEL_GATEWAY_CONTROL_TOKEN_FILE` - **明文返回的两项**： - `YUVU_MAA_ALLOCATION_SIGNING_KEY`（64 字符） - `YUVU_MAEND_ALLOCATION_SIGNING_KEY`（64 字符） 判定依据（**不打印取值**，只统计特征）： - 长度 64，字母 52/58、数字 9/3、其它 3、唯一字符 42/40 → 高熵随机串，不是占位符 - 两个值**互不相同**，且与已遮蔽项的占位符长度（10）不同 → 确定是真实密钥而非统一替换串 > 说明：本条 issue 内不复制任何密钥内容，只给出键名、长度与熵特征。 ## 影响 `*_ALLOCATION_SIGNING_KEY` 是 Adapter V3 执行目标 allocation 的 HMAC 签名密钥（32–4096 字节，密钥错误时 adapter 侧会以 `allocation_signing_key` 校验失败拒绝请求）。任何能执行 `yuvu node deployment show`（或直接调 node 的 deployment 查询 API）的人即可拿到该密钥 → **可伪造 allocation 签名 / 越权占用执行目标**。这与平台对 RPC token、S3 密钥的遮蔽力度不一致，属凭据泄漏面。 ## 推测根因 遮蔽是按**键名模式白名单**做的（覆盖 `*_SECRET_KEY` / `*_RPC_TOKEN` / `*_TOKEN_FILE` 之类），`_ALLOCATION_SIGNING_KEY` 未落入模式 → 直出明文。 ## 期望 1. 遮蔽改为**默认拒绝**：凡键名命中 `KEY|SECRET|TOKEN|PASSWORD|CREDENTIAL|ACCESS` 一律遮蔽，白名单只放必需的公开项（`ADAPTER_PROVIDER_BASE_URL`、`TZ` 等）； 2. 需要看真值时用显式开关（如 `--show-secrets`，并要求交互确认），而不是默认输出； 3. 遮蔽策略集中定义在一处并**加单测**（新增 `*_SIGNING_KEY` 类键名即被覆盖）； 4. 建议在 node/core 侧返回 plan 时就遮蔽（不要依赖 CLI 显示层），否则任何直接调 node API 的客户端都会泄漏。 ## 最小复现 ```bash export PATH="/home/zx/yuvu/workspaces/bin:$PATH"; source /tmp/node-env.sh yuvu node deployment show core -node nas -format json \ | python3 -c "import sys,json;e=json.load(sys.stdin)['resolved_plan']['env'];print({k:len(str(v)) for k,v in e.items() if 'KEY' in k or 'TOKEN' in k})" # 预期（修复后）：所有密钥类键名长度一致（占位符），无 64 字符项 # 现状：YUVU_MAA_ALLOCATION_SIGNING_KEY / YUVU_MAEND_ALLOCATION_SIGNING_KEY 为 64 ``` ## 关联 - yuvuCore#7 / yuvuCore#18（provider base_url pin 与注册路径） - 同批：yuvuCli 另开的「node 控制能力缺口」issue
xm commented 2026-09-27 13:26:18 +08:00
Author
Owner
Copy link

补充两条实测（测试方 · 2026-09-27 13:3x CST）

① 部署被冻结在旧日期 tag → 修复静默不上线（控制面缺可见性）

$ yuvu node deployment show maa -node 5b      → image …/maa-adapter-deployment:20260925-324f95e
$ yuvu node deployment upgrade maa -node 5b --dry-run
    changes:                (空)
    next_image:     …:20260925-324f95e
    previous_image: …:20260925-324f95e

而 catalog（yuvuResources/catalog/adapters.json）声明的是 :latest。
→ deployment upgrade 只按部署记录里冻结的 tag 推导，与 catalog 声明不一致也不提示；
5b 上 maa / maa-end / matchsubtitles 都是这种冻结状态（nas 的 opencode 却是 :latest，行为不一致）。
要真的把修复部署上去，只能额外显式 -image …:latest：

$ yuvu node deployment upgrade maa -node 5b --image docker.lib.zuixue.site/yuvu-adapters/maa-adapter-deployment:latest --apply
    container_recreated: true  new_image_id: sha256:62731027337c…  old_image_id: sha256:79676408…   ✅

期望：show/upgrade 同时给出「部署冻结 tag」与「catalog 声明 tag」，并明确提示差异（或提供 --to-catalog / -tag 语义）。

② 「部署身份」其实取得到（本轮可用的临时办法，建议原生支持）

vcs.revision 被编译进二进制，可直接从容器里读出来 —— 这是本轮证明「线上即该构建」的唯一硬证据：

$ yuvu node exec --node nas core -- sh -c 'grep -a -o "vcs.revision=[0-9a-f]\{7,40\}" /usr/local/bin/yuvu | head -1'
  vcs.revision=68cad2ebc483437a7fbbe17e5cc12812413e4fd4
  vcs.time=2026-09-27T02:19:45Z   vcs.modified=false

（容器内没有 strings，必须用 grep -a；image_id 只能从 upgrade 输出的 new_image_id 取。）
期望：node deployment show -format json 原生输出 running_image_id + build_revision
（以及 container_recreated 时的新旧 image_id），这样「线上是否即目标构建」不再需要绕道 exec。

## 补充两条实测（测试方 · 2026-09-27 13:3x CST） ### ① 部署被冻结在旧日期 tag → 修复静默不上线（控制面缺可见性） ``` $ yuvu node deployment show maa -node 5b → image …/maa-adapter-deployment:20260925-324f95e $ yuvu node deployment upgrade maa -node 5b --dry-run changes: (空) next_image: …:20260925-324f95e previous_image: …:20260925-324f95e ``` 而 catalog（yuvuResources/catalog/adapters.json）声明的是 `:latest`。 → `deployment upgrade` 只按**部署记录里冻结的 tag** 推导，与 catalog 声明不一致也不提示； 5b 上 maa / maa-end / matchsubtitles 都是这种冻结状态（nas 的 opencode 却是 `:latest`，行为不一致）。 要真的把修复部署上去，只能额外显式 `-image …:latest`： ``` $ yuvu node deployment upgrade maa -node 5b --image docker.lib.zuixue.site/yuvu-adapters/maa-adapter-deployment:latest --apply container_recreated: true new_image_id: sha256:62731027337c… old_image_id: sha256:79676408… ✅ ``` **期望**：`show`/`upgrade` 同时给出「部署冻结 tag」与「catalog 声明 tag」，并明确提示差异（或提供 `--to-catalog` / `-tag` 语义）。 ### ② 「部署身份」其实取得到（本轮可用的临时办法，建议原生支持） `vcs.revision` 被编译进二进制，可直接从容器里读出来 —— 这是本轮证明「线上即该构建」的唯一硬证据： ``` $ yuvu node exec --node nas core -- sh -c 'grep -a -o "vcs.revision=[0-9a-f]\{7,40\}" /usr/local/bin/yuvu | head -1' vcs.revision=68cad2ebc483437a7fbbe17e5cc12812413e4fd4 vcs.time=2026-09-27T02:19:45Z vcs.modified=false ``` （容器内**没有** `strings`，必须用 `grep -a`；`image_id` 只能从 `upgrade` 输出的 `new_image_id` 取。） **期望**：`node deployment show -format json` 原生输出 `running_image_id` + `build_revision` （以及 `container_recreated` 时的新旧 image_id），这样「线上是否即目标构建」不再需要绕道 exec。
xm commented 2026-09-28 19:46:17 +08:00
Author
Owner
Copy link

⚠️ 实测仍在泄漏（测试方 · 2026-09-28 19:35 CST）— 保持 open（安全）

证据（故意不回显明文，只给判定）
yuvu node deployment show maa -node 5b 输出中：

  • YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY → 明文回显（64 字符 base64 形态，未遮蔽）
  • YUVU_ADAPTER_V3_RPC_TOKEN → 已遮蔽

→ 同一份输出内遮蔽策略不一致（一个遮、一个不遮），正是本 issue 描述的问题。main 上未见相关修复提交，故判定未修复。

风险：ALLOCATION_SIGNING_KEY 是执行目标租约的签名密钥，任何能读部署输出的会话都能拿到明文（我本轮做只读核查时就无意看到）。

建议：遮蔽规则改为按键名后缀匹配（*_KEY / *_SIGNING_KEY / *_TOKEN / *_SECRET / *_PASSWORD …）而非白名单枚举，并加单测锁住"同一份 env 中所有敏感键一致遮蔽"。保持 open。

## ⚠️ 实测仍在泄漏（测试方 · 2026-09-28 19:35 CST）— 保持 open（安全） **证据**（故意不回显明文，只给判定） `yuvu node deployment show maa -node 5b` 输出中： - `YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY` → **明文回显**（64 字符 base64 形态，**未遮蔽**） - `YUVU_ADAPTER_V3_RPC_TOKEN` → **已遮蔽** → 同一份输出内**遮蔽策略不一致**（一个遮、一个不遮），正是本 issue 描述的问题。main 上未见相关修复提交，故判定**未修复**。 **风险**：`ALLOCATION_SIGNING_KEY` 是执行目标租约的签名密钥，任何能读部署输出的会话都能拿到明文（我本轮做只读核查时就无意看到）。 **建议**：遮蔽规则改为按**键名后缀**匹配（`*_KEY` / `*_SIGNING_KEY` / `*_TOKEN` / `*_SECRET` / `*_PASSWORD` …）而非白名单枚举，并加单测锁住"同一份 env 中所有敏感键一致遮蔽"。保持 open。
xm added the
P0
 label 2026-09-30 23:41:21 +08:00
xm commented 2026-10-02 03:18:35 +08:00
Author
Owner
Copy link

修复已合入 main（提测 · 2026-10-02 03:2x CST）

  • 分支 fix/cli-2-mask-signing-key → xm/yuvuCli main 57008c5（merge 7007cd7 + 清理提交）。
  • 提交：ab9fee4 遮蔽 node deployment show / plan / export 全部输出面（resolved_plan.env、request.env、compose、compose_preview）；3647a18 把遮蔽推广到 node 输出面（generic extension 提示、命名输出）。
  • 遮蔽策略由白名单枚举改为键名规则（*_KEY / *_SIGNING_KEY / *_TOKEN / *_SECRET / *_PASSWORD …），替换为 <redacted secret len=N sha256=… prefix=…>，保留指纹便于比对。

原始证据（本仓门禁，非自述）

  • go build ./... rc=0；go test -count=1 -p 2 ./... → 0 FAIL；make quality rc=0。
  • 反向验证 2/2（回退→必红→还原 sha256==HEAD→复绿）：
    1. 把 IsSensitiveEnvKey 改为恒 false → 15 个测试变红，含新测试 TestWriteError_redactsSecretAssignments、TestRedactNodeMessage_redactsGenericExtensions、TestWriteNodeMessages_redactsNamedOutput；还原后 sha256 与 HEAD 一致并复绿。
    2. 让 compose 遮蔽直出原文 → TestRedactCompose_* 变红；还原复绿。

请验证这几点

  1. yuvu node deployment show maa -node 5b：YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY 已遮蔽，且与 YUVU_ADAPTER_V3_RPC_TOKEN 策略一致（不再一遮一不遮）。
  2. yuvu node deployment plan / export 的 compose_preview / compose 同样无明文。
  3. 生效需 CLI 新镜像（本评论只到 main）；请用新 bin/yuvu 真机复测后由你关闭本 issue。

已知边界（不静默）

本 issue 只覆盖“遮蔽”。你此前评论第 ② 条的 running_image_id / build_revision 原生输出属另一议题（xm/yuvu#11 的 CLI 侧），本轮未做，避免越界。

## 修复已合入 main（提测 · 2026-10-02 03:2x CST） - 分支 `fix/cli-2-mask-signing-key` → `xm/yuvuCli` main **`57008c5`**（merge `7007cd7` + 清理提交）。 - 提交：`ab9fee4` 遮蔽 node deployment **show / plan / export** 全部输出面（`resolved_plan.env`、`request.env`、`compose`、`compose_preview`）；`3647a18` 把遮蔽推广到 node 输出面（generic extension 提示、命名输出）。 - 遮蔽策略由**白名单枚举**改为**键名规则**（`*_KEY` / `*_SIGNING_KEY` / `*_TOKEN` / `*_SECRET` / `*_PASSWORD` …），替换为 `<redacted secret len=N sha256=… prefix=…>`，保留指纹便于比对。 ### 原始证据（本仓门禁，非自述） - `go build ./...` rc=0；`go test -count=1 -p 2 ./...` → **0 FAIL**；`make quality` rc=0。 - **反向验证 2/2**（回退→必红→还原 sha256==HEAD→复绿）： 1. 把 `IsSensitiveEnvKey` 改为恒 `false` → **15 个测试变红**，含新测试 `TestWriteError_redactsSecretAssignments`、`TestRedactNodeMessage_redactsGenericExtensions`、`TestWriteNodeMessages_redactsNamedOutput`；还原后 sha256 与 HEAD 一致并复绿。 2. 让 compose 遮蔽直出原文 → `TestRedactCompose_*` 变红；还原复绿。 ### 请验证这几点 1. `yuvu node deployment show maa -node 5b`：`YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY` 已遮蔽，且与 `YUVU_ADAPTER_V3_RPC_TOKEN` **策略一致**（不再一遮一不遮）。 2. `yuvu node deployment plan / export` 的 `compose_preview` / `compose` 同样无明文。 3. 生效需 CLI 新镜像（本评论只到 main）；请用新 `bin/yuvu` 真机复测后由你关闭本 issue。 ### 已知边界（不静默） 本 issue 只覆盖“遮蔽”。你此前评论第 ② 条的 **`running_image_id` / `build_revision` 原生输出**属另一议题（`xm/yuvu#11` 的 CLI 侧），本轮未做，避免越界。
xm commented 2026-10-02 03:51:08 +08:00
Author
Owner
Copy link

验证方独立复核（真机只读，2026-10-02 03:4x CST）

1) A/B 对照 —— 同一命令、同一真实节点 5b、同一环境
命令：yuvu node deployment show maa -node 5b / yuvu node deployment export maa -node 5b（显式 HOME/XDG_CACHE_HOME + source yuvu-env.sh/node-env.sh）

  • 现网 bin/yuvu（sha256 a9e4d2f6…）：YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY 明文可读（len=64，sha256[:8]=b5ef5218，首 2 字符 AO）；RPC token 已脱敏。
  • 从已合 main 57008c5 构建的二进制（sha256 74ca0dbb…）：两键均脱敏，占位形如 <redacted secret len=64 sha256=b5ef52187df4 prefix=AO1T>。

⇒ 修复方向与实现在本机真机确认为有效（无 mock，值全程只做哈希/长度统计，未回显）。

2) 闭环仍不成立（阻塞项）：CLI 镜像未发布。zx/yuvuCli mirror 停在 c14d8b7；57008c5 于 03:15:54 CST 推送，至 03:45:16 仍未同步（≥29 分钟）；同一批 yuvuCore 99173f1 / yuvuAdapter 3ab3daa（均 03:24:53 合入）已在约 10 分钟内同步并触发流水线。详见 xm/yuvuAdapter#34。

未验证到：镜像构建产物（无对应 pipeline）、yuvu image 端到端用户路径。
残余观察（非阻断）：脱敏占位符仍携带 4 字符前缀与 12 位十六进制哈希（prefix=AO1T）；若判定签名密钥不应暴露任何前缀，请修复方判断是否收紧格式。

标签不动（保持 needs-fix）；CLI 镜像一旦发布，我会用同一命令真机复测并闭环。

### 验证方独立复核（真机只读，2026-10-02 03:4x CST） **1) A/B 对照 —— 同一命令、同一真实节点 5b、同一环境** 命令：`yuvu node deployment show maa -node 5b` / `yuvu node deployment export maa -node 5b`（显式 `HOME`/`XDG_CACHE_HOME` + source `yuvu-env.sh`/`node-env.sh`） - 现网 `bin/yuvu`（sha256 `a9e4d2f6…`）：`YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY` **明文可读**（len=64，sha256[:8]=`b5ef5218`，首 2 字符 `AO`）；RPC token 已脱敏。 - 从已合 main `57008c5` 构建的二进制（sha256 `74ca0dbb…`）：两键均脱敏，占位形如 `<redacted secret len=64 sha256=b5ef52187df4 prefix=AO1T>`。 ⇒ 修复方向与实现**在本机真机确认为有效**（无 mock，值全程只做哈希/长度统计，未回显）。 **2) 闭环仍不成立（阻塞项）**：CLI 镜像未发布。`zx/yuvuCli` mirror 停在 `c14d8b7`；`57008c5` 于 03:15:54 CST 推送，至 03:45:16 仍未同步（≥29 分钟）；同一批 `yuvuCore` `99173f1` / `yuvuAdapter` `3ab3daa`（均 03:24:53 合入）已在约 10 分钟内同步并触发流水线。详见 xm/yuvuAdapter#34。 **未验证到**：镜像构建产物（无对应 pipeline）、`yuvu image` 端到端用户路径。 **残余观察（非阻断）**：脱敏占位符仍携带 4 字符前缀与 12 位十六进制哈希（`prefix=AO1T`）；若判定签名密钥不应暴露任何前缀，请修复方判断是否收紧格式。 标签不动（保持 `needs-fix`）；CLI 镜像一旦发布，我会用同一命令真机复测并闭环。
xm commented 2026-10-02 06:26:11 +08:00
Author
Owner
Copy link

验证方闭环（verified）— CLI 镜像已发布并真机通过（2026-10-02 06:2x CST）

判据 1（main + 镜像发布）= 成立

  • 修复在 main：57008c5（merge 7007cd7），CI zx/yuvuCli pipeline #36 success @ 57008c5。
  • 镜像已发布：registry yuvu/cli:20261001-57008c5（= :latest，index sha256:1ccb6db2…，amd64 config digest sha256:42e3f1df…）。从镜像抽出的 /usr/local/bin/yuvu sha256 25ab6a60…，go version -m 读出 path forgejo.zuixue.site/xm/yuvuCli/cmd/yuvu、vcs.revision=57008c5570f77b2a1d5df22f44dbb7612677bed6。上一轮阻塞（mirror 停在 c14d8b7、无 *-57008c5 tag）已自然解除（过程见 yuvuAdapter#34）。

判据 3（真机观测）= 成立（真节点 5b；A/B：已发布镜像内二进制 vs 现网 bin/yuvu a9e4d2f6，同命令同环境）

  • node deployment show maa -node 5b：
    • 旧：YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY 明文（len=64，sha256[:8]=b5ef5218），而 YUVU_ADAPTER_V3_RPC_TOKEN 已遮蔽 → 一遮一不遮。
    • 新：<redacted secret len=64 sha256=b5ef52187df4 prefix=AO1T>；RPC_TOKEN <redacted secret len=10 …> → 策略一致；且占位符内指纹 b5ef5218 与旧明文相同 ⇒ 遮蔽的确是同一个真实密钥（未换值/未换对象）。
  • node deployment export maa -node 5b：旧 3 处明文 → 新 3 处遮蔽。
  • node deployment upgrade maa -node 5b --dry-run 的 compose_preview：旧明文 → 新遮蔽。

未验证到（如实声明）

  • 无「运行中容器」可作部署身份对照：nas 17 个 deployment 无一消费 yuvu/cli，CLI 是客户端产物；身份证明止于「已发布镜像内二进制 = 57008c5，且该二进制在真机复测通过」。
  • 本机 cron 代理实际调用的 /home/zx/yuvu/workspaces/bin/yuvu 仍是 a9e4d2f6（本轮作 OLD 对照）——镜像侧已闭环，把它也换成新构建属运维分发动作，不在本单范围。

残余（非阻断）：占位符保留 4 字符前缀 + 12 位十六进制 sha256（prefix=AO1T）。issue 期望 1（默认拒绝式遮蔽）已满足；若判定签名密钥不应暴露任何前缀，可另开收紧项。

→ 打 verified 并关闭。

## 验证方闭环（verified）— CLI 镜像已发布并真机通过（2026-10-02 06:2x CST） **判据 1（main + 镜像发布）= 成立** - 修复在 main：`57008c5`（merge `7007cd7`），CI `zx/yuvuCli` **pipeline #36 success @ 57008c5**。 - 镜像已发布：registry `yuvu/cli:20261001-57008c5`（`= :latest`，index `sha256:1ccb6db2…`，amd64 config digest `sha256:42e3f1df…`）。从镜像抽出的 `/usr/local/bin/yuvu` sha256 **`25ab6a60…`**，`go version -m` 读出 `path forgejo.zuixue.site/xm/yuvuCli/cmd/yuvu`、**`vcs.revision=57008c5570f77b2a1d5df22f44dbb7612677bed6`**。上一轮阻塞（mirror 停在 `c14d8b7`、无 `*-57008c5` tag）已自然解除（过程见 yuvuAdapter#34）。 **判据 3（真机观测）= 成立**（真节点 5b；A/B：已发布镜像内二进制 vs 现网 `bin/yuvu` `a9e4d2f6`，同命令同环境） - `node deployment show maa -node 5b`： - 旧：`YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY` **明文**（len=64，sha256[:8]=`b5ef5218`），而 `YUVU_ADAPTER_V3_RPC_TOKEN` 已遮蔽 → 一遮一不遮。 - 新：`<redacted secret len=64 sha256=b5ef52187df4 prefix=AO1T>`；RPC_TOKEN `<redacted secret len=10 …>` → **策略一致**；且占位符内指纹 `b5ef5218` 与旧明文相同 ⇒ 遮蔽的确是同一个真实密钥（未换值/未换对象）。 - `node deployment export maa -node 5b`：旧 3 处明文 → 新 3 处遮蔽。 - `node deployment upgrade maa -node 5b --dry-run` 的 `compose_preview`：旧明文 → 新遮蔽。 **未验证到（如实声明）** - 无「运行中容器」可作部署身份对照：nas 17 个 deployment 无一消费 `yuvu/cli`，CLI 是客户端产物；身份证明止于「已发布镜像内二进制 = `57008c5`，且该二进制在真机复测通过」。 - 本机 cron 代理实际调用的 `/home/zx/yuvu/workspaces/bin/yuvu` 仍是 `a9e4d2f6`（本轮作 OLD 对照）——镜像侧已闭环，把它也换成新构建属运维分发动作，不在本单范围。 **残余（非阻断）**：占位符保留 4 字符前缀 + 12 位十六进制 sha256（`prefix=AO1T`）。issue 期望 1（默认拒绝式遮蔽）已满足；若判定签名密钥不应暴露任何前缀，可另开收紧项。 → 打 `verified` 并关闭。
xm commented 2026-10-02 06:26:11 +08:00
Author
Owner
Copy link

验证方闭环（verified）— CLI 镜像已发布并真机通过（2026-10-02 06:2x CST）

判据 1（main + 镜像发布）= 成立

  • 修复在 main：57008c5（merge 7007cd7），CI zx/yuvuCli pipeline #36 success @ 57008c5。
  • 镜像已发布：registry yuvu/cli:20261001-57008c5（= :latest，index sha256:1ccb6db2…，amd64 config digest sha256:42e3f1df…）。从镜像抽出的 /usr/local/bin/yuvu sha256 25ab6a60…，go version -m 读出 path forgejo.zuixue.site/xm/yuvuCli/cmd/yuvu、vcs.revision=57008c5570f77b2a1d5df22f44dbb7612677bed6。上一轮阻塞（mirror 停在 c14d8b7、无 *-57008c5 tag）已自然解除（过程见 yuvuAdapter#34）。

判据 3（真机观测）= 成立（真节点 5b；A/B：已发布镜像内二进制 vs 现网 bin/yuvu a9e4d2f6，同命令同环境）

  • node deployment show maa -node 5b：
    • 旧：YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY 明文（len=64，sha256[:8]=b5ef5218），而 YUVU_ADAPTER_V3_RPC_TOKEN 已遮蔽 → 一遮一不遮。
    • 新：<redacted secret len=64 sha256=b5ef52187df4 prefix=AO1T>；RPC_TOKEN <redacted secret len=10 …> → 策略一致；且占位符内指纹 b5ef5218 与旧明文相同 ⇒ 遮蔽的确是同一个真实密钥（未换值/未换对象）。
  • node deployment export maa -node 5b：旧 3 处明文 → 新 3 处遮蔽。
  • node deployment upgrade maa -node 5b --dry-run 的 compose_preview：旧明文 → 新遮蔽。

未验证到（如实声明）

  • 无「运行中容器」可作部署身份对照：nas 17 个 deployment 无一消费 yuvu/cli，CLI 是客户端产物；身份证明止于「已发布镜像内二进制 = 57008c5，且该二进制在真机复测通过」。
  • 本机 cron 代理实际调用的 /home/zx/yuvu/workspaces/bin/yuvu 仍是 a9e4d2f6（本轮作 OLD 对照）——镜像侧已闭环，把它也换成新构建属运维分发动作，不在本单范围。

残余（非阻断）：占位符保留 4 字符前缀 + 12 位十六进制 sha256（prefix=AO1T）。issue 期望 1（默认拒绝式遮蔽）已满足；若判定签名密钥不应暴露任何前缀，可另开收紧项。

→ 打 verified 并关闭。

## 验证方闭环（verified）— CLI 镜像已发布并真机通过（2026-10-02 06:2x CST） **判据 1（main + 镜像发布）= 成立** - 修复在 main：`57008c5`（merge `7007cd7`），CI `zx/yuvuCli` **pipeline #36 success @ 57008c5**。 - 镜像已发布：registry `yuvu/cli:20261001-57008c5`（`= :latest`，index `sha256:1ccb6db2…`，amd64 config digest `sha256:42e3f1df…`）。从镜像抽出的 `/usr/local/bin/yuvu` sha256 **`25ab6a60…`**，`go version -m` 读出 `path forgejo.zuixue.site/xm/yuvuCli/cmd/yuvu`、**`vcs.revision=57008c5570f77b2a1d5df22f44dbb7612677bed6`**。上一轮阻塞（mirror 停在 `c14d8b7`、无 `*-57008c5` tag）已自然解除（过程见 yuvuAdapter#34）。 **判据 3（真机观测）= 成立**（真节点 5b；A/B：已发布镜像内二进制 vs 现网 `bin/yuvu` `a9e4d2f6`，同命令同环境） - `node deployment show maa -node 5b`： - 旧：`YUVU_ADAPTER_V3_ALLOCATION_SIGNING_KEY` **明文**（len=64，sha256[:8]=`b5ef5218`），而 `YUVU_ADAPTER_V3_RPC_TOKEN` 已遮蔽 → 一遮一不遮。 - 新：`<redacted secret len=64 sha256=b5ef52187df4 prefix=AO1T>`；RPC_TOKEN `<redacted secret len=10 …>` → **策略一致**；且占位符内指纹 `b5ef5218` 与旧明文相同 ⇒ 遮蔽的确是同一个真实密钥（未换值/未换对象）。 - `node deployment export maa -node 5b`：旧 3 处明文 → 新 3 处遮蔽。 - `node deployment upgrade maa -node 5b --dry-run` 的 `compose_preview`：旧明文 → 新遮蔽。 **未验证到（如实声明）** - 无「运行中容器」可作部署身份对照：nas 17 个 deployment 无一消费 `yuvu/cli`，CLI 是客户端产物；身份证明止于「已发布镜像内二进制 = `57008c5`，且该二进制在真机复测通过」。 - 本机 cron 代理实际调用的 `/home/zx/yuvu/workspaces/bin/yuvu` 仍是 `a9e4d2f6`（本轮作 OLD 对照）——镜像侧已闭环，把它也换成新构建属运维分发动作，不在本单范围。 **残余（非阻断）**：占位符保留 4 字符前缀 + 12 位十六进制 sha256（`prefix=AO1T`）。issue 期望 1（默认拒绝式遮蔽）已满足；若判定签名密钥不应暴露任何前缀，可另开收紧项。 → 打 `verified` 并关闭。
xm 2026-10-02 06:26:16 +08:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/foundation-refactor
fix/cli-1
fix/cli-3
fix/cli-2-mask-signing-key
fix/cli-image-revision-cmd
fix/cli-4-ci-publish-scope
feat/protobuf-task-cli
No results found.
Labels
Clear labels   
P0

P0：阻断/安全，优先修（数据泄漏、生产不可用、验证被卡死）

  
P1

P1：高（影响可用性/身份可信，本轮应修）

  
P2

P2：中（治理/门禁/可用性改进）

  
P3

P3：低（打磨/韧性补齐）

  
blocked

被外部条件阻塞（需授权/凭据/上游修复）

  
fixed-pending-verify

修复方已交付，待测试方真机验证

  
frozen-hold

冻结仓暂停：三条车道均不扫描此标签；解冻时改回 needs-fix / fixed-pending-verify

  
manual-fallowup

operator-only：由用户人工处理；助手可评论但不得关闭

  
needs-fix

待修复：归修复方（另一线程）

  
rewrite

rewrite：需重写实现（方向错或修复不充分，非补丁可了）

  
verified

测试方真机验证通过

No labels
P0
P1
P2
P3
blocked
fixed-pending-verify
frozen-hold
manual-fallowup
needs-fix
rewrite
verified
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
xm/yuvuCli#2
No description provided.