feat: signed manifests live in the image registry; updaters and first deploys fetch and verify them without the panel [CI]

docs/deployment.md

@@ -318,6 +318,21 @@ sh packaging/update/install-updater.sh agent --user \
 
 一行安装：页面给的命令先下载静态安装脚本（`/install`，所有人拿到的字节都一样）并核对它的 SHA-256，一致才执行；面板地址、角色、一次性码、信任根指纹（`MOSHIRO_GENESIS`）和属主（`MOSHIRO_CONTROLLERS`）走环境变量，都是公开值，没有私钥。脚本向面板取 CI 签名的发布清单（`/install/manifest`、`/install/manifest.sig`），用脚本里内置的发布公钥（`packaging/update/release-key.pub.pem`）验签，再按清单里的 digest 拉镜像（`镜像仓库@sha256:…`）；签名对不上、组件不对或 digest 格式不对就拒绝安装；需要本机有 `openssl`（Windows 用 .NET 自带的）。面板还没有这个组件的已签名清单时，设 `MOSHIRO_ALLOW_UNVERIFIED=1` 和 `MOSHIRO_IMAGE=镜像` 才会安装。CI 把脚本的 SHA-256 写进签名清单和发布页，面板的「系统 → 信任」页显示它和清单是否一致。详见 [access.md](access.md) 第 0 节。
 
+## 签名清单放在镜像仓库里（更新和首次部署都不依赖面板）
+
+CI 给每个镜像的 digest 签名之后，除了（面板在线时）登记给面板，**一定会把签名清单推到镜像仓库**：`<镜像仓库>-manifest:<通道>`，例如 `registry.oeo.one/moshiro-dev/moshiro-backend-manifest:dev`、`registry.oeo.one/moshiro/moshiro-backend-manifest:release`。它是一个没有任何文件层的小镜像，清单和签名放在标签 `org.moshiro.manifest`（base64）和 `org.moshiro.signature` 里。`dev` 通道每次 `[CI]` 构建都会更新，`release` 通道只在打 tag 时更新，所以不发 Release 的构建照样能被更新到。
+
+```text
+ 信任锚点：仓库里的发布公钥 packaging/update/release-key.pub.pem（随安装脚本和 deploy-node.sh 分发）
+ 取清单的人：宿主机更新器（定时）、deploy-node.sh（首次部署）：pull 清单镜像 → 读标签 → 本机公钥验签 → 按清单里的 digest 拉真正的镜像
+ 仓库、网络、面板都不需要可信：被改只会让验签失败；面板不在线、清库、没有 CI 都不影响
+```
+
+- **更新器**：配置里 `FEED=auto`（默认）时先看仓库里的清单，验签通过才用；取不到或验不过就用面板放进信箱的那份。`MANIFEST_REF` 可以指定清单镜像，`FEED=off` 关掉；通道取配置里的 `CHANNEL`，没有就按仓库路径推断（`moshiro-dev` → dev，`moshiro` → release）。仓库里的清单验签失败而信箱里又没有东西时，状态会报「无效清单」而不是悄悄当作没有更新。
+- **首次部署**：`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、换钥、仓库不可用回退、首次部署的验签）。
+
 ## Backend 签名更新
 
 Backend 也会收到 CI 发布的签名清单，但只提示管理端，不会自动重启。管理员确认精确的清单序号后，宿主更新器才会备份 Backend 数据 volume、按清单 digest 拉取镜像、重启服务并检查 `/healthz`；失败时恢复旧镜像和数据库备份。确认和发布通过同一个锁串行处理，避免确认过期版本。