feat!: genesis-pinned operator set, server identity with an encrypted control link, key-less join codes; release key continuity
Join codes need no passkey touch and carry only public values (genesis fingerprint, owner credentials, installer hashes). Nodes pin the genesis and owners at enrollment and only follow passkey-signed operator set versions. The panel's server key is listed in the set; pinned nodes require its signature and run the control link under AES-256-GCM. Password sessions carry no capabilities. The updater adopts a next_key from a signed manifest. Bump version to 0.2.0. [CI SKIP]
This commit is contained in:
justme committed
1 parent
9bb6841dce
commit
a2f88a344b
89 files changed
+2145
-1195
No files matched your search
+96
-25
@@ -1,9 +1,38 @@
|
||||
# 访问控制与入网信任链
|
||||
|
||||
这份文档定义**谁能做什么**（账户、角色、能力、API key）和**谁能让节点入网**（passkey 到节点的签名链）。它是 [security.md](security.md) 第 5、6 节的展开：security.md 讲为什么（缺口和威胁），这里讲怎么做。**状态：设计已定，未实现**（实施顺序见第 12 节）。
|
||||
这份文档定义**谁能做什么**（账户、角色、能力、API key）和**谁能让节点入网**（passkey 到节点的签名链）。它是 [security.md](security.md) 第 5、6 节的展开：security.md 讲为什么（缺口和威胁），这里讲怎么做。**状态：部分实现**（当前实现见第 0 节，完整设计的实施顺序见第 12 节）。
|
||||
|
||||
一句话：登录和授权分开。登录证明「你是谁」，密码、passkey、OIDC 都可以；改变信任（加节点、吊销、改凭证）只认 passkey 的签名，并且这个签名要一路传到节点，Backend 只搬运，伪造不了。
|
||||
|
||||
## 0. 当前实现（以这一节为准）
|
||||
|
||||
下面的第 1～16 节是完整设计，其中「成员证明」那一整套（Grant、Ticket、Binding、每个节点的入网链，第 7.1～7.3 节）**当前没有采用**：评估之后，被攻破的 Backend 往名册里塞节点拿不到比 Backend 已经有的更多的东西（监测数据本来就是明文给 Backend 的；敏感的 extension 靠节点属主，不靠名册），成本却是每个节点一次触碰、一套证明格式和一套自动化委托。现在实现的是它的精简版：
|
||||
|
||||
```text
|
||||
两个根，各管一摊
|
||||
根 A：CI（代码） 发布公钥写在安装脚本和节点二进制里
|
||||
└─ CI 签名的发布清单 → 镜像 digest → 节点跑的二进制；安装脚本的 SHA-256 也记在清单里，并公布在发布页
|
||||
假设：CI（Woodpecker、Gitea、镜像仓库、发布密钥）可信；CI 被攻破等于能给所有节点签恶意更新
|
||||
根 B：你的 passkey（运维）
|
||||
└─ 操作员集合（passkey 签，版本递增；创世指纹在安装时固定到节点）
|
||||
├─ 操作员的 passkey 公钥
|
||||
├─ 服务器密钥：Backend 的身份密钥（节点据此认服务器，链路用应用层加密）
|
||||
└─ 域名（rp、origins）
|
||||
|
||||
添加节点：创建加入码不需要 passkey、不需要触碰，一个码可以装任意多台。命令里只有公开的值：
|
||||
面板地址、角色、一次性码、创世指纹、属主（passkey 凭证 id）、安装脚本的哈希（命令先核对哈希再执行）
|
||||
节点注册：向面板取操作员集合链，从命令里的创世指纹验起，属主必须是集合里的凭证；任何一步不对就不注册、不交出密钥；
|
||||
通过后写 trust.json（创世指纹、链、属主），之后只认从这个创世出发的新版本
|
||||
节点和 Backend 之间：集合里登记了服务器密钥之后，节点的认证挑战要求服务器用它签名；两边各出一把临时 ECDH 密钥，
|
||||
认证签名覆盖双方的临时公钥，之后控制链路每一帧都是 AES-256-GCM（每个方向一把密钥、严格递增的计数器）。
|
||||
所以 TLS 在 Cloudflare 或被冒充的证书那里终止，中间人没有服务器密钥，既冒充不了服务器，也读不了、改不了这条链路
|
||||
密码登录的会话没有任何能力，只能注册 passkey；有能力的会话来自 passkey 登录；信任类操作要提权窗口（passkey 触碰）
|
||||
```
|
||||
|
||||
**发布密钥可以换**：见 `docs/deployment.md` 的「换发布密钥」；回滚已经由清单的 `seq` 防住（更新器只收比已安装更大的）。
|
||||
|
||||
**还没有的**：吊销表；任务和配置内容的操作员签名；节点自证跑的是官方构建；extension 本身和属主的 `controllers`、接收者的实际加密（只是被固定在节点本地，没有行为）。
|
||||
|
||||
## 1. 名词
|
||||
|
||||
| 名词 | 含义 |
|
||||
@@ -105,24 +134,11 @@
|
||||
- 现有令牌迁移（破坏性）：`read` → 全部 `*.read`；`admin` → 全部非信任类能力；`release` → `release.publish`。迁移后，旧的 admin 令牌不能再生成加入代码，需要换成 `enroll` key。
|
||||
- 每把 key 可设：有效期、可选的 IP 白名单（CIDR，**待确认**）、`enroll` 类的数量上限和单券 TTL 上限；预留：资源范围、速率和数据配额（见 5.4）。
|
||||
|
||||
### 5.2 `enroll` key 怎么工作
|
||||
### 5.2 `enroll` key：自动化添加节点
|
||||
|
||||
```text
|
||||
创建（浏览器 + passkey 一次触控）
|
||||
浏览器生成种子 S，只显示一次（形如 mok_…）
|
||||
认证值 = HKDF(S, "auth") → Backend 只存哈希，用来识别这把 key
|
||||
签名密钥 = HKDF(S, "sign") → 公钥 P 写进委托；私钥只有拿着 S 的人算得出
|
||||
passkey 对委托签名：{P, scope=enroll, not_after, max_ticket_ttl, 数量上限, 签发凭证 id}
|
||||
Backend 存委托和认证值哈希，不存 S
|
||||
**当前实现：它就是一把带 `fleet.enroll` 的普通 API key**，用 `POST /api/admin/join-tokens` 创建加入码，响应里直接给出安装命令（带创世指纹、属主和脚本哈希，没有任何私钥）。因为创建码不是信任动作，所以不需要 passkey，也不需要提权窗口；CI 和脚本照常工作。信任在两处：命令里的创世指纹和属主由面板生成，节点注册时固定；以后改属主和集合要操作员 passkey 签名。
|
||||
|
||||
使用（和普通令牌一样的 HTTP 调用）
|
||||
POST /api/admin/join-tokens Authorization: Bearer mok_S
|
||||
Backend 用请求带来的 S 现算签名密钥，签出入网券和 K_code，返回一行安装命令；用完即忘
|
||||
```
|
||||
|
||||
- 数据库被偷走拿不到任何签名密钥。被攻破的 Backend 最多在 key 被使用的那一刻拿到 S，权力受这把 key 的有效期和单券 TTL 限制，key 过期或被撤销就没用了。
|
||||
- 数量上限由 Backend 执行，**节点强制不了**；节点只强制时间（见第 7.3 节）。
|
||||
- CI 和测试：夹具自己生成 key 种子，把公钥写进测试的操作员集合，不需要真 passkey。
|
||||
早先设计过的「委托密钥」（passkey 签一次委托，API key 自己签入网券，节点验证整条链）属于第 7.1～7.3 节的完整设计，当前没有采用，见第 0 节的取舍。
|
||||
|
||||
### 5.3 创建界面
|
||||
|
||||
@@ -154,7 +170,9 @@
|
||||
- 审计日志 `(时间, 账户, 凭证 id, 动作, 对象, 详情)`：创建或撤销 key、加入代码、吊销、删除、手填地址、确认更新、提权、因能力不足被拒绝的请求。保留 365 天（同事件表）。
|
||||
- **可验证的一层**：委托里写进签名它的 passkey 凭证 id，入网券和节点绑定带着它，节点在 hello 里报告「由哪个凭证准入」。「谁加的」不只是 Backend 的一面之词。
|
||||
|
||||
## 7. 入网信任链
|
||||
## 7. 入网信任链（完整设计，当前没有采用；当前实现见第 0 节）
|
||||
|
||||
> 第 7.1～7.3 节描述的 Grant、Ticket、Binding、成员证明和节点验证在代码里**不存在**。要不要叠加回来，取决于你要不要防「被攻破的 Backend 往名册里塞节点」；操作员集合和创世固定已经在，叠加时不用重装节点。
|
||||
|
||||
### 7.1 文档
|
||||
|
||||
@@ -221,6 +239,18 @@
|
||||
|
||||
不在这个切片里：重启和改配置不需要签名的票；webssh 等 extension 见第 8 节。
|
||||
|
||||
### 7.6 当前实现要点
|
||||
|
||||
- 语句是 `key=value` 文本，第一行是带版本的标题，签名覆盖整段文本；WebAuthn 的挑战是语句的 SHA-256。库在 `Fleet.Identity` 的 `OperatorTrust`（操作员集合的编码、解析、链验证）和 `SecureChannel`（服务器证明和链路加密），都是只用 BCL 的纯函数，节点和 Backend 共用。
|
||||
- **创世**：第一次建立信任根时，把账号下所有 passkey 和这个面板的服务器密钥登记成一个操作员集合，passkey 对它签名；创世语句的 SHA-256 就是命令里的 `MOSHIRO_GENESIS`。之后加删 passkey 或换服务器密钥要签新版本（上一版里的凭证签），页面会提示；签名更新不会让节点重装。
|
||||
- **操作员集合版本**随期望状态（`trust_chain`）下发，节点从固定的创世验起，版本比现有的新才采用并保存。
|
||||
- **节点注册**：`fleet-enroll --genesis … --controllers …`：先 `POST /api/agent/v1/enroll/trust` 取链，验过（创世指纹、签名、属主在集合里）才把密钥交出去；之后写 `trust.json`。没有命令里的指纹（`--genesis`）就不固定，节点按旧方式工作。
|
||||
- **服务器身份和安全链路**：`ChallengeParams` 带服务器的临时公钥和签名（`server_eph`、`server_sig`），`AuthParams` 带节点的临时公钥（`node_eph`），节点签名的用途是 `auth2`，覆盖双方的临时公钥；通过后两边用 HKDF 派生每个方向一把 AES-256-GCM 密钥，每帧 `计数器(8) ‖ 密文 ‖ 标签(16)`，计数器严格递增，明文帧、改动、重放、乱序一律断开。集合里没有服务器密钥的节点（旧节点）保持明文，不会被降级成放行。
|
||||
- **服务器密钥**存在 Backend 的设置里（`server.identity_key`）：它防的是面板被冒充，不是面板被攻破；面板被攻破时它也泄露，那时要由 passkey 签一个换掉它的新集合版本。集合里没有这个面板的服务器密钥的版本，Backend 不收（否则固定了它的节点就认不出这个面板了）。
|
||||
- **安装脚本是静态的**：不替换任何值，所以 SHA-256 固定；CI 把哈希写进签名的发布清单和发布页，面板的信任页显示它和清单是否一致；命令先下载、核对哈希，一致才执行。
|
||||
- **密码登录的会话没有任何能力**，只能注册 passkey；创建加入码需要 `fleet.enroll`，不需要提权窗口。
|
||||
- **现状的缺口**：没有吊销表；删除一把操作员 passkey 只是让它不能再签新版本；任务和配置没有操作员签名；节点没有自证构建；服务器密钥换新要靠签一个新集合版本，忘了签会让固定了集合的节点认不出面板（fail closed）。
|
||||
|
||||
## 8. 节点属主与 extension 授权（预留）
|
||||
|
||||
后面会做 extension（web ssh、文件、抓包，见 [security.md](security.md) 第 11 节）。这类能力**连管理员都不信任**：管理员能删，不能读，也不能用。所以入网链现在就要给每个节点留出「属主」这个概念，即使 extension 还没做，字段也先固定下来，之后不用重装节点。
|
||||
@@ -249,21 +279,46 @@
|
||||
- **属主是 passkey 凭证，不是账户**：账户只是 Backend 里给人看的标签；节点只认公钥。一个人丢了全部属主 passkey，这个节点上的 extension 就没人能用了，要用就得重装节点（和第 3 节的恢复一致），所以添加时建议绑两把以上。
|
||||
- 属主字段在**步骤 4（入网链）**就写进 Ticket；extension 本身、ControllerUpdate 和能力令牌放在阶段六。
|
||||
|
||||
### 8.1 添加节点时选属主（接口现在就留）
|
||||
### 8.0 范围：这一节先固定协议和要求，extension 本身先不做
|
||||
|
||||
- API：`POST /api/admin/join-tokens` 和 `enroll` key 的签发请求都带可选的 `controllers: [credential_id…]`；缺省 = 签发账户的全部 passkey。校验：每个 id 必须是已注册的 passkey（任何账户的都可以，比如把同事的一把加进来），数量不超过上限。
|
||||
- 界面：「添加 Agent / Probe」对话框里一个「属主 passkey」多选列表，按账户分组，带**全选**、组内全选和反选；默认勾选自己的全部；至少选一把；提示「只有这些 passkey 能授权这个节点上的 web ssh 等敏感能力，管理员也不能」。
|
||||
- 节点详情页显示属主（凭证 id 和所属账户），以及「由谁绑定」；改属主走 `ControllerUpdate`，需要现有属主签名，管理员做不了。
|
||||
- 没有 extension 的现阶段，这组字段只是被签名、被节点持久化，不起别的作用。
|
||||
- **web ssh、文件、抓包等 extension 现在都不实现**，Agent 和 Probe 一样（Probe 是节点，同样要在本地执行下面的要求）。这里只把「谁来强制」和「怎么证明」定下来，以后实现时不改信任链，也不用重装节点。
|
||||
- **已经固定在节点本地的字段**：`controllers`（允许授权本节点 extension 会话的 passkey 凭证 id，必须是操作员集合里的凭证）由安装命令带来，节点注册时保存在 `trust.json`，Backend 之后改不了；从集合里去掉的凭证不再有效。默认是操作员集合里的全部凭证，空 = 不允许任何 extension 会话。接收者名单（`recipients`）等做加密时再加。节点还没有 extension，所以现在只是被固定和保存，不起别的作用。
|
||||
|
||||
### 8.2 数据用属主的私钥解密：Backend 解不开，也改不了
|
||||
### 8.1 添加节点时选属主
|
||||
|
||||
- API：`POST /api/admin/join-tokens` 带可选的 `controllers: [credential_id…]`；缺省 = 操作员集合里的全部凭证。校验：每个 id 必须是操作员集合里的凭证。
|
||||
- 界面：「添加 Agent / Probe」对话框里一个「属主（passkey）」多选列表；只是选，不用触碰。选定的写进安装命令，节点装上时固定。
|
||||
- 以后改属主要现有属主的 passkey 签名（`ControllerUpdate`，没有实现）；管理员改不了。
|
||||
|
||||
### 8.2 谁来强制：节点本地，不是 Backend
|
||||
|
||||
web ssh 这类会话要不要加密、要不要验证，**由 Agent（和 Probe）自己要求**，不是 Backend。Backend 是被防的一方：让它决定，被攻破的 Backend 一句「这次不用加密」或自己充当会话的一端就绕过去了。所以要求落在节点本地，Backend 只能转发：
|
||||
|
||||
| 节点本地强制的要求 | 为什么不能交给 Backend |
|
||||
|---|---|
|
||||
| 没有操作员的现场证明就不启动会话 | Backend 说「已经授权过了」不算数 |
|
||||
| 会话密钥只和证明里的那把密钥协商，不和 Backend 转来的任何公钥协商 | 否则 Backend 换一把自己的公钥就成了中间人 |
|
||||
| 加密字段缺失就拒绝，没有明文降级 | 防降级 |
|
||||
| 能开哪些 extension、哪些 passkey 能授权，只看本节点属主（passkey 签的 `controllers`） | Backend 改不了属主，账户角色也不赋予任何权力 |
|
||||
| 这些要求写在节点本地（编进二进制或本地 `trust.json`），Backend 下发的配置、任务、更新清单都覆盖不了 | 配置是 Backend 能碰的东西 |
|
||||
|
||||
**要求证明的方向是反的：节点向请求者要证明，不信任 Backend 的转述。** 一次会话由节点先出题（nonce 加它的临时公钥，用节点身份密钥签名），浏览器把这个 nonce 和自己的临时公钥一起放进 passkey 断言的挑战里（见 8.3 的流程）；节点验：断言来自固定的操作员集合里的凭证、要求用户验证、挑战里的节点 id、extension、过期时间都对得上、这把凭证在本节点的 `controllers` 里、nonce 是它自己刚出的且没用过。任何一条不满足，节点直接拒绝，不看 Backend 的任何说法。
|
||||
|
||||
**Backend 在这件事里仍然管**：谁有资格发起请求（一项 `extensions.use` 能力）、审计、限流、转发密文。这些只挡「不该问的人」；真正的放行始终是节点本地验过证明之后。
|
||||
|
||||
**交互式会话和静态数据用不同的密钥**：
|
||||
- 交互式会话（终端、ssh）：现场签名的临时密钥协商，**不依赖 PRF**，passkey 只用来签名授权，不参与解密，所以不支持 PRF 的 passkey 也能用，还有前向保密。
|
||||
- 静态数据（抓包文件、会话录像）：需要事后解密，才用接收者名单里的公钥加密（`recipients`，来自 WebAuthn PRF 或浏览器里的不可导出密钥，见 8.3）。
|
||||
|
||||
### 8.3 数据用属主的私钥解密：Backend 解不开，也改不了
|
||||
|
||||
目标：交互式会话（web ssh、终端）、以及以后 extension 产生的数据（文件、抓包），**只有属主 passkey 对应的私钥能解开**。Backend 被篡改或被攻破，拿到的只有密文，且改动密文会被发现。
|
||||
|
||||
```text
|
||||
浏览器（属主） Backend（只搬运） 节点上的 extension
|
||||
⓪ 节点先出题：nonce 和它的临时公钥 n，签名后经 Backend 转给浏览器（见 8.2：要求证明的是节点）
|
||||
① 生成会话临时 ECDH 密钥 e
|
||||
② passkey 对「e 的公钥 ‖ 节点 ID ‖ 命令哈希 ‖ nonce ‖ not_after」做 WebAuthn 断言（能力令牌）
|
||||
② passkey 对「e 的公钥 ‖ 节点 ID ‖ 命令哈希 ‖ 节点出的 nonce ‖ not_after」做 WebAuthn 断言（能力令牌）
|
||||
──────────── 能力令牌 + e 公钥 ───────▶ 转发 ─────────────────────────▶ ③ 验：断言来自本节点属主
|
||||
+ 令牌新鲜、nonce 未用
|
||||
◀── 节点的会话公钥（节点身份密钥签名）── 转发 ◀────────────────────────── ④ 节点生成临时密钥 n，签名后返回
|
||||
@@ -281,6 +336,20 @@
|
||||
属主记录里没有 `enc_pubkey` 的节点只支持实时会话，不能存加密的静态数据。
|
||||
- 加密发生在属主这一侧的浏览器和节点上的 extension 之间，不经过 Backend 的任何账户、角色、会话机制，所以改 Backend 的数据库或代码也无从下手。
|
||||
|
||||
### 8.4 数据边界：哪些明文，哪些加密，谁能解
|
||||
|
||||
| 数据 | 形态 | 谁能读 |
|
||||
|---|---|---|
|
||||
| **监测数据**（延迟、丢包、吞吐曲线、事件、主机资源汇总） | **明文**：Backend 要做分析、聚合和展示页 | 有 `data.read` 等能力的人和 key |
|
||||
| **extension 会话**（web ssh、文件、抓包等，以后）、原始 payload | **端到端加密**：节点加密给接收者名单里的公钥，Backend 只存和转发密文 | 只有接收者私钥的持有者 |
|
||||
|
||||
- **读取权不是能力，是私钥**：Backend 不持有任何接收者私钥，所以 `data.read`、`data.export` 对加密流只返回密文。API key 解不开，除非你登记过读者密钥。
|
||||
- **接收者名单由操作员固定**（做加密时和 `controllers` 一样，写进安装命令并固定在节点本地；现在还没有加密功能）：
|
||||
- 默认只有操作员自己的 passkey（经 WebAuthn PRF 派生的公钥）。
|
||||
- 接入密钥签出来的码，名单必须和操作员签的接入委托完全一致：它能让节点加入，不能让节点把数据加密给自己。
|
||||
- **读者密钥**（预留）：自动化想读明文，要操作员用 passkey 显式登记一把读者公钥（范围、有效期），私钥由读者自己保管；吊销只管之后的数据，已经加密给它的历史数据它仍然能解。
|
||||
- 管和读互不相通：passkey 或接入密钥能让节点加入和批准，但不能解密；解密靠私钥，Backend 被攻破也拿不到。
|
||||
|
||||
## 9. 流程
|
||||
|
||||
| 流程 | 步骤 |
|
||||
@@ -317,6 +386,8 @@
|
||||
4. **入网链**：Grant、Ticket（含属主 `controllers`）、Binding 的签发和节点验证（验证一次、缓存结果）；成员条目随期望状态下发、节点在状态同步时验证；Probe 只拨公网地址；`enroll` key；节点信任状态上报和管理页显示（第 14 节）。添加节点的界面可以选属主（默认添加者的全部 passkey）。
|
||||
5. **吊销表与操作员集合更新**；自动化夹具（测试里的软件 ECDSA 凭证）；**安装脚本的供应链**（第 15 节：静态签名脚本、按 digest 拉镜像）。
|
||||
|
||||
实现状态：能力模型、passkey 登录、提权窗口、审计、操作员集合与创世固定、服务器身份和安全链路、静态安装脚本和哈希核对、属主固定都已实现（第 0 节）；成员证明（第 7.1～7.3 节）没有采用；吊销表、任务和配置的操作员签名、节点自证构建、extension 属主的实际强制还没有做。
|
||||
|
||||
## 13. 局限
|
||||
|
||||
- 数量上限只能由签名人执行，节点只强制时间；窗口过期后设备被攻破的人，最多还能多签有效期内的入网券（受节点时钟约束）。
|
||||
|
||||
+8
-1
@@ -307,7 +307,14 @@ sh packaging/update/install-updater.sh agent --user \
|
||||
|
||||
发布私钥只放在 Woodpecker 的 `release_signing_key` secret；发布公钥位于 `packaging/update/release-key.pub.pem`。CI 的 `release_api_token` 只有发布登记权限，`RELEASE_API_URL` 指向面板。面板保存并转发签名清单，Agent/Probe 将它与更新请求写进配置 volume；更新器验签后才调用容器引擎和 systemd。管理端仍能看到可更新、更新中、已回滚和无效清单状态。纯二进制更新器尚未实现。
|
||||
|
||||
一行安装会验证镜像：脚本向面板取 CI 签名的发布清单（`/install/manifest`、`/install/manifest.sig`），用脚本里内置的发布公钥（`packaging/update/release-key.pub.pem`）验签，再按清单里的 digest 拉镜像（`镜像仓库@sha256:…`），签名对不上、组件不对或 digest 格式不对就拒绝安装；需要本机有 `openssl`（Windows 用 .NET 自带的）。面板还没有这个组件的已签名清单时，设 `MOSHIRO_ALLOW_UNVERIFIED=1` 才会按标签安装。脚本本身的完整性（哈希核对）见 [access.md](access.md) 第 15 节。
|
||||
**换发布密钥**（泄露或定期轮换，不用重装节点）：
|
||||
|
||||
1. 生成新密钥对；CI 给发布流水线加 `RELEASE_NEXT_KEY`（新公钥 PEM），仍用旧私钥签名。清单里会带 `next_key`（SPKI DER 的 base64）。
|
||||
2. 宿主机更新器验过这份清单后，把新公钥存到自己的状态目录（`<组件>.key.pem`），之后只认新密钥，旧密钥签的清单一律拒绝。清单里的 `next_key` 不是合法公钥就整份拒绝。
|
||||
3. 下一个版本起把 `release_signing_key` 换成新私钥、去掉 `RELEASE_NEXT_KEY`，并把 `packaging/update/release-key.pub.pem`、`install.sh`、`install.ps1` 里的公钥换成新的（安装脚本哈希随清单变化）。
|
||||
4. 还没收到过渡清单的节点（离线很久）会因为签名对不上而停在旧版本，需要手动换 `release-key.pub.pem`；旧密钥泄露时，这些节点是唯一的暴露面。
|
||||
|
||||
一行安装：页面给的命令先下载静态安装脚本（`/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 节。
|
||||
|
||||
## Backend 签名更新
|
||||
|
||||
|
||||
+1
-1
@@ -305,7 +305,7 @@ Agent 和 Probe 的核心永远是纯采集器。**所有敏感能力**（exec
|
||||
1. 敲门先做等级一，等级二先记 TODO（已按此实现等级一）。
|
||||
2. 严格程度：节点没有固定操作员公钥就拒绝一切 Backend 给的对端（默认），弱信任模式是安装时的显式选择（见 access.md 第 8 节）。
|
||||
3. 节点面和外部面是否拆成两个监听端口（8.1 的目标）：拆的话部署文档、Caddy 和隧道的配置都要跟着改。
|
||||
4. extension 的交互式会话**已定**：端到端加密，Backend 只转发密文（见 access.md 第 8.2 节）；剩下的是静态数据私钥来源和 AEAD 的选择。
|
||||
4. extension 的交互式会话**已定**：端到端加密，Backend 只转发密文（见 access.md 第 8.2 和 8.3 节）；剩下的是静态数据私钥来源和 AEAD 的选择。
|
||||
5. extension 的第一个具体实现做不做 web ssh，放在哪个阶段。
|
||||
6. 块摘要固定 SHA-256，不预留算法字段（不协商、不降级，见第 9.4 节）。
|
||||
7. Agent 的 `max_total_mbps` 默认值调到多少（第 9.5 节），比如 100。
|
||||
|
||||
Reference in new issue
Block a user