refactor: remove the runtime binary binding; every release registration path verifies the CI signature [CI]

The hash a node reports about itself cannot be trusted (a swapped binary can
copy the old hash), so the runtime binding only caught files that were replaced
by something that did not lie. Provenance stays where it can be verified: the
signed release manifest (digest) and the signed SHA256SUMS.

- Remove BinaryBindingService, the node_bindings table (schema v15 drops it),
  BinaryPolicy, the handshake hash/manifest fields and the admin binary column.
- Drop the per-platform "binaries" list from the release manifest, the hash
  scripts and the updater's installed.manifest copy.
- ReleaseService.PublishAsync now verifies the release signature, so the admin
  POST /releases route is no longer an unsigned path; tests sign with a test key.
- Docs: section 16 explains why the runtime check is gone.

docs/access.md

@@ -10,7 +10,7 @@
 
 ```text
  两个根，各管一摊
-   根 A：CI（代码）  发布公钥写在安装脚本和节点二进制里
+   根 A：CI（代码）  发布公钥写在安装脚本、宿主机更新器的本机配置和 Backend 里
         └─ CI 签名的发布清单 → 镜像 digest → 节点跑的二进制；安装脚本的 SHA-256 也记在清单里，并公布在发布页
         假设：CI（Woodpecker、Gitea、镜像仓库、发布密钥）可信；CI 被攻破等于能给所有节点签恶意更新
    根 B：你的 passkey（运维）
@@ -32,9 +32,9 @@
 
 **发布密钥可以换**：见 `docs/deployment.md` 的「换发布密钥」；回滚已经由清单的 `seq` 防住（更新器只收比已安装更大的）。
 
-**节点二进制绑定**（第 16 节）：节点第一次握手成功的那一刻，Backend 把它正在运行的二进制的 SHA-256 绑定到这个节点；之后哈希对不上、又不在 CI 签名的更新清单里，就拒绝连接。
+**运行中的二进制不做校验**（第 16 节）：节点自报的哈希不可信，来源证明在安装时（签名的清单和 `SHA256SUMS`）。
 
-**还没有的**：吊销表；任务和配置内容的操作员签名；节点向别人**证明**自己没有撒谎（二进制绑定抓的是文件被换、降级、起了不对的二进制，抓不到故意照抄哈希的恶意二进制，见第 16 节）；extension 本身和属主的 `controllers`、接收者的实际加密（只是被固定在节点本地，没有行为）。
+**还没有的**：吊销表；任务和配置内容的操作员签名；节点向别人**证明**自己运行的就是官方二进制（需要容器之外的背书，见第 16 节）；extension 本身和属主的 `controllers`、接收者的实际加密（只是被固定在节点本地，没有行为）。
 
 ## 1. 名词
 
@@ -428,8 +428,6 @@ curl -fsSL https://panel/install -o /tmp/moshiro-install.sh && echo "<sha256>  /
 
 **② 镜像按 digest 拉取，二进制按 SHA-256 校验**
 - 脚本向面板取已签名的清单（和更新用的是同一份，发布密钥签名、`seq` 防回滚），用**脚本里内置的发布公钥**验签，再按清单里的 digest 拉镜像（`repo@sha256:…`）；原生二进制则核对清单里的 SHA-256 再安装。Backend 改不了 digest，最多让节点装到一个旧的合法版本。
-- 发布公钥因此既在脚本里，也编进 Agent 和 Probe 二进制（一个常量，来自 `packaging/update/release-key.pub.pem`），节点之后的更新由节点自己验，不依赖宿主机更新器和 Backend 转发的内容。发布密钥轮换时，新公钥必须由旧密钥签名的清单带下来，否则节点不认。
-- 更新建议要求**双签**：CI 的发布签名，加操作员 passkey 对清单摘要的批准签名。只攻破 CI 或只攻破 Backend 都不够。
 
 **③ 其余**
 - 角色（Agent 还是 Probe）、镜像仓库地址仍由代码决定，但镜像身份由签名清单决定。
@@ -486,25 +484,16 @@ curl -fsSL https://panel/install -o /tmp/moshiro-install.sh && echo "<sha256>  /
 11. 节点预算的数字（常驻内存 ≤ 1 MB、二进制 ≤ 150 KB、每个成员验证 ≤ 100 毫秒、成员上限 256）是否合适；超出预算时优先砍什么（比如先去掉操作员集合的 64 个凭证上限换成更小的）。
 12. webhook 和数据拉取的配额默认值（每分钟请求数、每天行数）和事件清单。
 
-## 16. 节点二进制绑定
+## 16. 运行中的二进制不做校验
 
-目的：被换掉的、版本被改的、降级的二进制，不能继续当这个节点运行。
+曾经做过「节点二进制绑定」：节点握手时自报正在运行的二进制的 SHA-256，Backend 在第一次握手时绑定，之后对不上就标红或拒绝。**已经移除。**
 
-```text
- CI 构建：算出镜像里节点二进制的 SHA-256，写进签名的清单（binaries）
- 宿主机更新器：把验过的清单和签名写进节点只读挂载的 update-status/（installed.manifest、installed.sig）
- 节点握手（auth 里）：binary = 正在运行的二进制的哈希（Linux 读 /proc/self/exe，是进程启动时映射的那个映像）
-                       release、release_sig = 上面那份清单和签名
- Backend：
-   ① 第一次握手成功 → 绑定 (节点, 哈希, 清单 seq)
-   ② 以后每次握手：哈希和绑定一致 → 放行
-   ③ 不一致 → 必须是一份 CI 签名清单（用内嵌的发布公钥验）里列出的官方二进制，并且清单 seq 不低于绑定时的（合法升级，改绑）；
-      否则拒绝连接，节点页标红「不符」。不许降级。
-```
+原因：哈希和清单都是节点自己报的。一个被换进来、故意撒谎的二进制可以照抄原来的哈希和清单，Backend 分辨不出——上报者就是被怀疑的对象。这一层只能抓到「文件被换了、但程序本身没撒谎」的情形，却让人误以为有保障，还要求运维宿主机更新器、状态卷和每个节点的清单。得不偿失。
 
-- **清单是节点带来的**，Backend 自己验签，所以不依赖面板有没有收到过这次发布；被攻破的 Backend 也加不进「官方」哈希（没有 CI 私钥）。
-- **旧节点**（不上报哈希）：没绑定过就放行（显示未绑定）；绑定过的不许退回不上报。
-- **没有更新器的节点**（二进制安装）没有清单，首次握手按上报的哈希绑定（显示「首次绑定」）；手工升级之后哈希变了，会被拒绝，管理员在「系统 → 版本」点「接受当前二进制」清除绑定，下一次连接重新绑定。
-- **策略** `MoShiro__BinaryPolicy`：`enforce`（默认）拒绝；`warn` 只记录不拒绝；`off` 不检查。
-- **边界**：哈希是节点自己报的。一个被换进来、故意撒谎的恶意二进制可以照抄原来的哈希，Backend 分辨不出——上报者就是被怀疑的对象。要堵这一点，必须让容器之外的东西背书：宿主机更新器用安装时绑定的密钥对「当前运行的镜像 digest + 挑战」签名，由 agent 转发；容器里的进程被换掉也伪造不了。这一步还没做。
+「这个资产是我们的」靠**安装时的来源证明**，那里的哈希来自另一个信道，伪造不了：
 
+- 安装脚本（SHA-256 记在签名的清单里，并公布在发布页），按清单里的 digest 拉镜像（`repo@sha256:…`）；
+- 下载压缩包的人用签名的 `SHA256SUMS` 核对（验签用 `packaging/update/release-key.pub.pem`）；
+- 节点的更新由宿主机更新器用本机公钥验签，只认本机配置的镜像仓库。
+
+要让运行中的二进制真的无法伪造，必须有容器之外的东西背书：宿主机更新器持有一把节点进程读不到的密钥，对「当前运行的镜像 digest + Backend 的挑战」签名，由节点转发；容器里的进程被换掉也伪造不了，除非攻破宿主机。这一步没有做（一键容器安装的节点也没有宿主机更新器）。

docs/api.md

@@ -150,7 +150,6 @@
 | POST | `/api/release/offer` | CI 登记发布清单的入口，**不需要令牌**：`{manifest, signature}` 的签名必须能用 Backend 内嵌的发布公钥验过（ECDSA P-256 / SHA-256，DER），否则 403；`seq` 必须比已登记的新，否则 409。登记不依赖面板里的任何凭证，清库、重装、还没有 passkey 时照常工作 |
 | GET | `/api/admin/links` | 每一对（Probe，Agent）的线路开关：`linked`（最终结果）、`override`（手动设置，`null` 跟随自动连接）、`connected`，以及 `auto_link` |
 | PUT | `/api/admin/links/{probe_id}/{agent_id}` | `{enabled: true｜false｜null}`：手动强制连或不连，`null` 取消手动设置；改完立即重新下发 |
-| DELETE | `/api/admin/nodes/{id}/binary` | 接受节点当前的二进制：清除它的二进制绑定，下一次握手重新绑定（需要 `fleet.write`；没有绑定也返回 204）。`GET /api/admin/build-info` 的每个节点带 `binary`（`sha256`、`signed`、`seq`、`bound_at`、`violation`） |
 | POST | `/api/admin/nodes/{id}/update` | 请求一个在线的 Agent 或 Probe 更新到它收到的清单（节点不在线返回 409） |
 | GET/POST/PATCH | `/api/admin/users` | 首次启动时通过命令行或环境变量创建初始管理员 |
 

docs/deployment.md

@@ -336,10 +336,8 @@ CI 给每个镜像的 digest 签名之后，除了（面板在线时）登记给
 
 - **更新器**：配置里 `FEED=auto`（默认）时先看仓库里的清单，验签通过才用；取不到或验不过就用面板放进信箱的那份。`MANIFEST_REF` 可以指定清单镜像，`FEED=off` 关掉；通道取配置里的 `CHANNEL`，没有就按仓库路径推断（`moshiro-dev` → dev，`moshiro` → release）。仓库里的清单验签失败而信箱里又没有东西时，状态会报「无效清单」而不是悄悄当作没有更新。
 - **面板自己取**：安装脚本向面板要某个组件的签名清单时，面板里没有（清过库、CI 登记那一步网络失败）或者已经放了十分钟以上，面板就按 OCI 分发协议**匿名**读一次仓库里的清单镜像（只读清单和它的配置两个小 JSON，不拉镜像层），用内嵌的 CI 发布公钥验过签才登记；验不过（仓库或路上被改）就当没有。所以清库之后不用手工补登记，也不会被一份伪造的清单骗到。仓库要匿名可读（`moshiro/**`、`moshiro-dev/**`）。
-- **没有宿主机更新器的节点**（一键容器安装、二进制安装）握手时带不来清单：面板用自己手里（登记时验过 CI 签名）的那份把节点的二进制标成「已签名」；不在清单里的只是不标「已签名」，不会因此被拒绝。
-- **发版**：打 `vMAJOR.MINOR.PATCH` tag 时，节点镜像（Agent、Probe 的多架构镜像）也和 Backend 一样签清单，放到 `moshiro/…-manifest:release`。清单里的 `binaries` 是**所有平台、所有架构**的发布压缩包里可执行文件的 SHA-256（Linux glibc 和 musl、macOS、Windows，x64 和 arm64，每个组件 8 个，`ci/release-binary-hashes.sh`），不只是容器镜像里的那两个：节点握手时上报正在运行的可执行文件的哈希，Backend 凭 CI 签名的清单认「官方二进制」，所以容器和直接下载压缩包安装的节点是一回事。
+- **发版**：打 `vMAJOR.MINOR.PATCH` tag 时，节点镜像（Agent、Probe 的多架构镜像）也和 Backend 一样签清单，放到 `moshiro/…-manifest:release`。
 - **压缩包的校验和也签名**：Release 里除了每个压缩包的 `.sha256`，还有汇总的 `SHA256SUMS` 和 `SHA256SUMS.sig`（用发布私钥签，base64 的 DER ECDSA P-256，和清单同一把密钥）。验证：`base64 -d SHA256SUMS.sig > s.bin && openssl dgst -sha256 -verify packaging/update/release-key.pub.pem -signature s.bin SHA256SUMS`，通过之后再 `sha256sum -c SHA256SUMS`。macOS 的 Developer ID 签名和公证、Windows 的 Authenticode 需要苹果和微软的证书，目前没有做。
-- 测试：`bash ci/tests/binary-hashes-test.sh`（本地的假包仓库，8 种平台的 tar.gz 和 zip，缺任何一个压缩包都会失败，不会悄悄少签）。
 - **首次部署**：`deploy-node.sh` 默认就走这条路，不需要面板，也不用手动指定镜像（Backend 第一次部署时本来就没有面板）。`--tag` 指定标签时不验签并有警告；`--image` 直接用你给的引用。
 - **别人自己部署后端，什么都不用改**：仓库对匿名读开放（`moshiro/*` 和各 `*-manifest` 仓库），然后 `sudo sh deploy-node.sh backend --channel release --public-url https://<自己的域名>`，只是配置，不改代码、不需要自己的 CI；passkey 绑定在自己的域名上。自己 fork 并自建镜像的人要换自己的发布公钥和仓库地址（`--image-repo`）并重新构建，这是 fork 的正常代价。
 - 测试：`bash packaging/update/tests/feed-test.sh`（假的 podman + 真的 openssl，覆盖篡改、别的密钥、旧 seq、换钥、仓库不可用回退、首次部署的验签）。

docs/enrollment.md

@@ -10,7 +10,7 @@
 | Probe | Fleet 节点身份（连面板）+ 另一把独立的密钥（连 Agent，放在 `tls.pfx`） | `fleet-enroll`，和 Agent 一样用加入令牌（`role=probe`）；可以有多个 Probe，每个独立吊销 | 两把公钥 |
 | 面板用户 | 账号 + 密码（PBKDF2-SHA256） | 面板 | 密码哈希 |
 | API 令牌 | 随机高熵令牌，带一组能力（见 [access.md](access.md)） | 面板 | SHA-256 |
-| 发布签名 | ECDSA P-256 发布密钥 | CI（Woodpecker 密钥 `release_signing_key`）或离线环境 | 只在节点宿主机的更新器里配置公钥（容器节点是 `moshiro-update`，见 [deployment.md](deployment.md)；纯二进制节点的更新是待办），**面板不保存私钥，也不验签** |
+| 发布签名 | ECDSA P-256 发布密钥 | CI（Woodpecker 密钥 `release_signing_key`）或离线环境 | 只在节点宿主机的更新器里配置公钥（容器节点是 `moshiro-update`，见 [deployment.md](deployment.md)；纯二进制节点的更新是待办），**面板不保存私钥**；登记清单时面板用公钥验签，节点宿主机的更新器之后再验一次 |
 
 ## 2. Agent 接入流程