 chick
|
20070b90f7
|
fix: enroll 写出守护进程会拒绝的配置，install 写出与自身路径不符的单元
四处"校验在错误的层"的缺陷，都属于同一类：每个组件单独看都对，接缝错了。
1. `msa-agent enroll --relay http://relay.example` / `relay.example` /
`https://relay.example/v1` 都会写出配置文件，install 报成功，守护进程在**下一次启动**才
拒绝，日志里只有一行 "msa-agent exiting"。规则原本散在三处（config 只查非空、transport
查真实规则、enroll 的注册客户端另有一份），现在收进 `internal/relayurl` 一份，三处都调它。
`config.File.Validate` 因此也补上了 https/host/无路径/无 query 的检查。
2. `enroll` 不再自己手写字段检查，改为构造真正的 `config.File` 并调用真正的 `Validate`——
一份"什么是可用配置"的定义，结构上无法再漂移。`config.Marshal` 让 enroll 与 Save 用同一个
编码器。
3. `install --config /srv/msa/config.json` 会给该文件改属主、交给服务用户，然后写一个
ExecStart 指向 `/etc/msa-agent/config.json` 的单元——服务起来找不到配置就退出，而它需要的
文件就在别处、属主正确、从未被读。`enroll --audit /srv/audit/audit.log` 同理：单元的
`ReadWritePaths` 只覆盖 `/var/log/msa-agent`，在 `ProtectSystem=strict` 下 agent 的
`MkdirAll` 报 EROFS，进程启动即退出，报错既不提那个 flag 也不提那条指令。现在单元是模板，
`RenderedUnit` 按实际布局渲染，`--print-unit` 打印的就是会被写入的那一份；默认布局渲染结果
与仓库里被 review 过的文件逐字节相同，所以 vendored 副本的漂移检查仍然有意义。
测试：新增 `internal/relayurl`，`config`/`enroll`/`install` 各补回归测试。每条都做了变异验证
（把修复回退，对应测试必须失败）。
|
2026-09-18 12:38:56 +08:00 |
|
|
chick
|
af738a5bf9
|
fix(relay): 限额改为从共享策略推导，修掉信封上限过小导致的合法请求被拒
中继此前自带一份限额常量，并在注释里声称"与共享策略一致"，而没有任何东西
校验这句话。其中两条已经漂移成真实缺陷：
1. 信封上限 64 KiB 是**信封**的上限，而信封约为其承载 body 的 1.8 倍（body
先 base64、再 AEAD、再 base64）。于是 body 仍在 agent 的 256 KiB
maxRequestBytes 之内的请求，在中继处被拒为 relay_payload_too_large——一个
在局域网上能成功、走中继就失败的操作。响应方向同理：节点返回合法的大
body，应答在中继被拒，手机白等到超时。实测 120 KiB 的 body 就被拒。
2. mailboxDepth 只靠注释与策略"相等"，改任一侧都不会有人发现，而这个深度
是 agent 重放缓存容量的依据。
现在 relay/src/limits.js 从 contracts/agent-policy.json 推导全部限额，并在
文件不可读、缺 limits、数值不可用时**拒绝启动**：中继无法区分"诚实的大请求"
与"内存耗尽尝试"，上限是它唯一的工具，凭空发明一个等于在强制一个没人选过的
数字。推导结果：信封上限 513037 字节、深度 8、请求期限 30s、轮询窗口 24s。
策略摘要在健康检查里公开并逐节点对比：/healthz 返回中继自己那份的摘要，以及
每个在线节点上报的摘要与 policyMatches。它只上报不强制——中继读不到节点上的
文件，声称不一致就拒服务会把"节点跑着旧二进制"变成一次故障；而策略本来就是
agent 在强制。没有上报的节点显示 null 而不是 false，"没说"与"说了不一样的"
是两个不同的发现。
顺带修掉一个只在 sudo 配对时才暴露的缺陷：config.Save 用临时文件加重命名，
在 root 下会把配置文件变成 root 所有，而 systemd 单元以 msa-agent 用户运行，
于是配对看起来成功、节点重启后读不到自己的配置。现在重命名前保留原文件的
uid/gid，且无法保留时报错而非警告。
测试新增 test/limits.test.js（11 项），分三层：推导与策略文件一致、推导出的
上限确实容得下用真实 wire 代码构造的最坏信封（这是旧上限失败的那次测量）、
以及经真实 HTTP 面把合法大请求送过去。另有健康检查的摘要上报与 null 语义。
四处断言都做了变异验证：把上限改回 64 KiB，四项测试失败。
Node 93 项、Go 全包、Swift 99 项、端到端全部通过。
|
2026-09-16 23:24:28 +08:00 |
|
|
chick
|
78e0d303ab
|
feat: 配对管理端点与中继侧设备注册上报
- agent --pair：临时监听 :3001 仅开放 /provision 与 /destroy，以节点密码为共享秘密；
窗口由三个独立条件关闭（首次成功配对 / 失败尝试 10 次 / 10 分钟超时），配对成功后
管理监听即关（设计 §7 第 4 步）
- agent 为每台配对手机生成中继 bearer（config.Save 0600 原子写；启动时为手写条目补发）
- transport.PushDevices：握手成功后全量上报本节点受信设备集；空集是吊销声明而非无操作
- relay /v1/agent/devices：agent 会话后鉴权的设备注册；全量替换本节点条目；
操作员 MSA_DEVICES 为 static 不可被覆盖；跨节点 id 不可抢占
- 中继设备注册替代了 §11 第 6 项的一部分：节点 destroy + 重握手即可在路由层吊销
- 配置：provisionSecret 字段（无密码保护节点需显式设置才可配对）；Validate(pairMode)
- 测试：pair 流程 8 项、设备注册 6 项、transport 1 项；文档 §7 实现修订注记与 README 状态
|
2026-09-16 11:43:52 +08:00 |
|
|
chick
|
54d9696a4d
|
baseline: P1 契约、agent 核心与中继投递（既有工作首次入库）
|
2026-09-16 08:41:13 +08:00 |
|