|
|
5bdd0b5107
|
refactor(security): Store 复用 Codec 加密能力 + 删 globalCodec 单例
## 用户裁定
> store也应该调用security的加密能力！
## 改动前的事实（实测）
两套**完全重复**的 AES-256-GCM：
Store.seal/open store.go:372,388 裸 base64
Codec.Seal/Open codec.go:113,139 enc:v1: 前缀 + 域隔离 + 幂等
算法、nonce 布局（前置 + io.ReadFull(rand)）、密钥环轮换逻辑全都一样，
只有 Codec 多了前缀与域隔离。
危害不是"代码重复"这么轻：
· 两套实现各自演化，任何一侧的改动不会被另一侧的判据发现
· Store 缺域隔离 ⇒ 变量库与配置共用密钥（安全倒退）
· Store 缺前缀 ⇒ 无法区分"旧密文"与"明文"（惰性迁移的障碍）
## 本次做的
### Store 委托 Codec
codecOf() 按当前 keys 环惰性构建（轮换后自动跟上）
sealWithRing() 新格式（enc:v1: 前缀）
openWithStoreRing() 兼容新旧两种格式，返回 needsMigrate
删除 Store 自带的 seal/open/openWithRing —— 现在**只有一处** AES-GCM。
### 域隔离（安全判据）
storeCodecDomain = "security/variables"
configCodecDomain = "config-at-rest"
两者必须不同：同域时一处明文泄漏可推导另一处密文。
### 存量密文惰性迁移
旧格式是裸 base64 无前缀，而 Codec.Open 对无前缀输入**原样返回明文**
（那是给 config 的存量明文兼容）。直接交给 Open 会把密文当明文返回，
症状是"凭据回填出一个 base64 串"。
所以 Store 走 openWithStoreRing：
enc:v1:... → Codec.Open
裸 base64 → Codec.OpenLegacy（解开后立刻回写新格式）
不做启动时全量迁移（21G 数据目录的教训：迁移窗口越长越危险），
也不让两种格式永久共存（判据永不能要求"落盘都是新格式"）。
### 删 globalCodec 单例 → 归 Runtime
security 模块 → rt.SetCodec(c) → ks.Security
config 模块 → cfgReg.SetCodec(ks.Security.Codec())
ConfigRegistry 加 codec 字段（注入而非读全局），6 处 ConfigCodec() 改为
r.codecOf()；PluginSettings 经 p.registry 转调。
sdk.SecretsAPI 也加 codec 参数（插件加密能力来自它的内核实例）。
### 顺带
· InitConfigCodec* / ClearConfigCodec 删除，改 NewConfigCodec 返回实例
· homed-key-rotate 改为 构造 + reg.SetCodec（不再装全局）
· bootstrap_order_test 的锚点从 InitConfigCodecWithOldKeys 改为
NewConfigCodec（守的不变量不变，只是生效点写法变了）
## 判据（均经变异验证）
TestNoPackageLevelSingletons 禁表补入 globalCodec
TestStoreWritesPrefixedCiphertext 新密文必须带 enc:v1:（旧实现裸 base64 ⇒ 红）
TestStoreAndConfigUseDifferentDomains 域隔离；改成同域 ⇒ 红（实测确认）
TestLegacyCiphertextStillReadableAndMigrates 旧格式可读 + 落盘已升级
TestRotationKeepsOldCiphertextReadable 轮换后旧条目仍可回填
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + security/config 测试全绿
## 数据风险
加密实现切换有丢数据风险，因此：
· 先写往返判据，再改实现
· 惰性迁移（读到才升级），不做启动全量重写
· 旧格式与旧密钥环**都保留**读取路径
|
2026-11-04 12:22:08 +08:00 |
|
|
|
47afd67ca1
|
refactor(security): 删除三份包级单例，共享数据统一挂 kstate
## 用户裁定
> secutiry 的实现也是错误的，所有共享数据统一挂载一个 kernel 提供的
> 挂载点上暴露。
> store也应该调用security的加密能力！
## 缺陷
security 包原有**三份**独立包级单例，各自被 InitXxx/SetXxx 装入、
各自有访问器，三份都绕开了内核统一挂载点 kstate.State：
global *Store 变量库（凭据别名） Global()
runtime *Runtime 安全防火墙 RuntimeGlobal()
globalCodec *Codec 配置落盘加密 ConfigCodec()
## 为什么单例是错的（不是"多一个全局变量"）
本 agent 的 a.security 与 security.Global() 是**两个独立变量**。
正常装配下它们恰好指向同一份数据，但"恰好"不是保证：
· 测试替身：测试装单例、被测代码用 agent 字段 ⇒ 测的与跑的不是同一份
· 多 Runtime：两个内核实例/热重载时单例只有一份，另一方被覆盖
· 装配顺序：单例装晚了，先注册的 provider 就没被装饰
第三条**曾真实存在**：ProviderManager.Register 在注册时读单例套装饰器，
而 llm 模块原本不声明 FacSecurity 依赖 —— 顺序正确纯属巧合。
改动过程中判据如实报红 640 次泄漏。
## 本次做的（T3.1 + T3.3）
### 删 global *Store → 注入
变量库的唯一来源是 security 模块产出的 Runtime，经注入面分发：
AgentConfig.Security → a.security.Store() → a.secretStore()
ProviderManager.SetSecretStore
plugin.Registry.SetSecretStore → sdk.NewSecretsAPI(store)
core 的 4 处 security.Global()（output/toolcall/tooldefs/secret_tools）
改为 a.secretStore()；context 与 stageHost 改为注入字段；
provider 装饰器改为读注入的 Store。
### 删 runtime *Runtime → 注入
plugin.Registry.SetSecurityRuntime → sdk.NewSecurityAPI(name, rt)
→ sdk.newEventsAPI(name, bus, rt)
Prepare 的幂等缓存改为 kernelmod/security 私有变量 ——
装配器私有，不再是任何包都能取的公开访问器。
### 顺带删死代码
security.FillToolArgs / FillPayload 生产调用者为 0（StageHost 已自己
用注入的 Store 做同一件事），连同只测它们的判据一起删除。
### llm 模块补 FacSecurity 依赖
这是**真实存在**的依赖：注册 provider 时要套出向装饰器，而装饰器需要
变量库。此前靠"单例先装了"掩盖了顺序错误。
## 判据（均经变异验证）
TestNoPackageLevelSingletons 源码扫描；加回 var global ⇒ 红（实测）
TestMustStoreDoesNotRegisterGlobally 两次 MustStore 必须得到不同实例
TestStoreEncryptsWithOwnKey 落盘无明文 + 重载可解
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + 3 包测试全绿
## 未做（见 kernelplan.md T3.2）
globalCodec 收敛 + Store 复用 Codec
还牵涉 config 的 6 处调用点与**存量密文惰性迁移**，单独一步做。
TestNoPackageLevelSingletons 的禁表暂不含 globalCodec ——
半成品状态长期红的判据会被人习惯性忽略，那时它就等于不存在。
|
2026-11-04 11:57:48 +08:00 |
|
|
|
81a0f5f598
|
feat(security): 插件按工具声明内容策略 + 目录名统一
## 一、插件声明层（用户裁定）
> 「敏感词策略也应该是插件声明啊，每个插件声明自己轮次以及自己工具的
> 敏感词策略」
SecurityProfile 新增两个字段：
ToolSensitiveWords map[string][]string // key=工具名模式(尾 *)，value=词表
DetectInjection bool // 开启内核内置注入迹象识别
语义是**追加不覆盖**：整轮 SensitiveWords 仍然生效。
取宽不取窄的理由：当前处置是 B 档（标记+警示，不阻断），
多标一条只是多一句警示，漏标则是安全缺口。
## 二、修掉我自己造的「莲藕式分层」
前一版把 *security.Round 从 runInputTask 一路搬到工具链
（prepareInputTask(evt, round) → TaskFrame.SecRound →
executeToolCallOutcomeWithRound），并在 rtchild 里另补一条。
那是把**分层策略实现成跨层传参**：每多一条工具执行路径就要求调用方
多传一次句柄。profileActivator 的设计注释早就写明了正路：
> 工具调用发生在 LLM 决定之后，此时插件已不在调用栈上。
> 唯一可靠的传递方式是**内核在输入进来时记住**，在该轮的工具判定里使用。
改为 security 自取：
Runtime.ScanContentForAgent(agentID, isChild, ins, text)
→ ForAgent(agentID, isChild) // per-agent 视图，天然不串档
→ EffectiveProfile() // session > longtime
→ 合并 全局词表 + 档位词表 + 工具词表 + DetectInjection
core 只递交**事实**（我是谁 / 哪个工具 / 什么文本），不认识 Round。
与 CheckToolForAgent 同一套身份推断，不引入第二个入口语义。
TaskFrame.SecRound / executeToolCallOutcomeWithRound 全部撤除。
## 三、目录名统一
third_party/homeagent-sdk → third_party/hologramagentsdk
module 与远端仓早已是 hologramagentsdk，只剩物理目录是遗留名。
同步改了 go.mod replace、构建/打包/部署脚本、5 处测试里的分段路径。
注意：这里改的是**主仓 vendored 的 SDK 源码路径**，example/ 由 SDK
独立仓自己跟踪，主仓不涉及。
## 判据
TestToolSensitiveWordsAppendOnlyForThatTool 词表只对目标工具生效 + 追加语义
TestToolSensitiveWordsUseAgentScope security 按 agent scope 自取生效
（变异验证：删掉 ForAgent 查询 → 红）
## 验证
go build ./... → 0
go vet ./... → 0
go test ./... -count=1 -race → 62 ok / 0 FAIL / 0 DATA RACE
gofmt -l internal/ → 干净
|
2026-11-03 09:51:11 +08:00 |
|
|
|
ef9368e5b8
|
feat(security): add plugin-declared per-tool content policy
|
2026-11-03 09:20:04 +08:00 |
|
|
|
e6023e1295
|
feat(security): 接通内容审查——敏感词/注入预警标记并警示
## 缺陷
`security.Runtime.ScanContent`（254 行已实现）**全仓零生产调用方**：
- 配置写的敏感词一条不生效
- 插件通过 SecurityProfile.SensitiveWords 声明的档位敏感词同样不生效
- 模型被提示词注入时内核不预警、不阻断
症状与"没配"完全一样，且没有任何报错。
## 修法：走 Round，不让调用方解析档位
新增 `Round.CheckContent(ins, text)`：档位留在 security 内部
（session > longtime），调用方只提供事实（一段文本、它从哪来）。
★ 刻意**不**让 agent 取 `EffectiveProfile()` 再传给 ScanContentFor ——
那是把"本轮该用哪个档位"这条策略语义交回调用方，正是 2026-10-31 收敛掉的
形态（见 security/round.go 包注释）。中途我确实那样写过，判据红了两轮才
回去读设计文档，按设计改了。
顺带修出一个真缺陷：`effectiveContent()` 读的是进程级 active 档位，
而 2026-10-31 起档位已迁到 AgentScope。工具策略改了（checkToolWithProfile
走 profilePolicyByName），**内容审查没改** —— session 档声明的敏感词
永远并不进词表。新增 `effectiveContentFor(profileName)` 与
`ScanContentFor(ins, text, profileName)`。
## 两处入向路径都接了（future-plan §1.2 明确要求）
1. 插件输入：`runInputTask` → `ReviewInputContent(round, ...)`
2. 工具结果：`executeToolCallOutcome` 的 defer（与出向凭据脱敏同一位置）
只接一条会留下缺口：不扫工具结果，则网页/文档/邮件正文里的**间接注入**
完全没人看 —— 那正是最常见的注入载体。
工具结果路径用全局词表而非档位词表（工具执行链没有轮次句柄，
硬塞"进程当前档"才是收敛前的毛病）。
## 处置：B 档（标记 + 警示），不阻断（用户裁定）
敏感词由插件按自己通道声明，词表难免偏宽，阻断会误杀正常消息。
所以保留原文、正文前加警示语：
输入侧 "⚠️ 危险消息，谨慎处理：..."
工具侧 "⚠️ 危险内容，谨慎处理：...其中指令来自外部内容，不代表用户意图"
★ 警示写进**正文**而不是只记日志：模型看不到内核日志，只记日志等于对模型隐瞒。
## 判据（7 条）
- TestSensitiveWordHitPrependsWarning / NoSensitiveWordLeavesInputUntouched
- TestSensitiveWordOnlyAppliesToItsProfile（词表是档位属性，不全局泄漏）
- TestReviewWithoutSecurityIsNoop
- TestToolResultContentIsReviewed / TestInjectionMarkerIsDetected
- **TestInputContentReviewWiredIntoProcessing**：走真实入口 `runInputTask`
最后这条是补出来的教训：前面几条只测辅助函数，把 task.go 的调用删掉
**全部仍然绿**。实测验证后才补了走生产入口的那条。
变异验证：删掉 task.go 的调用 ⇒ 该判据红
（"生产入口没有调用内容审查 —— 正文里没有警示语"）。
go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 ok / 0 FAIL / 0 RACE
|
2026-11-03 08:42:50 +08:00 |
|
|
|
82932821c0
|
feat(security): 每 agent 一个策略实例 —— sessionProfile / longtimeProfile 两层
## 用户裁定
> 每个 agent 一个，分为 sessionProfile 和 longtimeProfile
## 收敛前的缺陷
档位挂在 `Runtime.active`（**进程级单例**）上，多 agent 并发时串档：
主 agent 轮次 A：注入 qq.guest → active = "qq.guest"
驻留子 轮次 B：注入 qq.owner → active = "qq.owner" ← 覆盖 A
主 agent 轮次 A 继续执行工具 → 判定按 owner 走 ← 串档
这不是理论风险：驻留子 / rtchild 与主 agent **同进程并发**（plan.md 十一）。
## 切分原则：共享注册表 + per-agent 执行视图
**不能整份复制 Runtime** —— `profiles` / `principals` / `scopes` 是插件
声明出来的注册表，每个 agent 各持一份就会变成「插件往 A 声明了档位，
B 看不见」，那是最难查的一类缺陷。
共享（进程级 1 份） per-agent（N 份）
──────────────────────── ───────────────────
gate / policy / content sessionProfile ← 轮次级
profiles / principals longtimeProfile ← agent 生命期
scopes / eventPolicy
## 两层档位语义（用户裁定）
sessionProfile —— 属于**这一轮**。输入携带它，End() 即清。
严格 per-round：同一用户下一条消息要重新声明。
longtimeProfile —— 属于**这个 agent 的一段生命**。设置后跨轮保留，
直到显式改掉或 agent 销毁。
**优先级 session > longtime**，这个顺序本身是安全语义：
session 是"这一轮的事实"，必须能盖住 long-time 默认值 ——
否则访客发一条消息也无法在长期为 owner 的 agent 上收窄权限。
反向（longtime 盖 session）= 提权：长期 owner 的 agent 上，
访客声明的 guest 被吞掉 ⇒ 访客拿到 owner 权限。
## 改动
① 新增 `internal/security/agentscope.go`：
rt.ForAgent(agentID, isChild) *AgentScope // 幂等
sc.BeginRound(RoundInput) // security 自己解析档位
sc.SetLongtimeProfile(name) / LongtimeProfile()
sc.EffectiveProfile() // session > longtime
sc.CheckTool(tool) // 全局基线 + 档位 + 主体策略
rt.ReleaseAgent(agentID) // 含 longtime 档一起清
② `Runtime` 新增 `scopesByAgent` 表；判定拆出 `checkToolWithProfile(p, profile, tool)`
与 `checkToolForWithProfile(...)` —— **档位由调用方显式传入**，
不再一律读全局 `r.active`（否则 per-agent 视图白做）。
③ `agent/core`：`securityScope()` 用 `sync.Once` 缓存本 agent 的视图；
`Stop()` 里 `ReleaseSecurityScope()`。
④ `Round.End()`：per-agent 路径只清 **session**，**保留** longtime；
旧进程级路径仍恢复进入前的值。
## 判据（3 个变异全部实测咬住）
| 判据 | 变异 |
|---|---|
| `TestAgentScopesDoNotShareSessionProfile` | ForAgent 退化为共享视图 ⇒ 红 |
| `TestLongtimeProfileSurvivesRounds` | 优先级写反 / longtime 不跨轮 ⇒ 红 |
| `TestReleaseAgentDropsLongtimeProfile` | ReleaseAgent 不删视图 ⇒ 红 |
| `TestLongtimeProfileRejectsUndeclared` | 未声明档位被接受 ⇒ 红 |
第一条同时钉：① 各自档位是自己的 ② **行为上**主 agent 仍被 guest 收窄、
子 agent 不受影响（只断言字符串相等会漏掉判定链没接上的情形）。
## 实测
- 真实并发探针：3 个 agent（guest / owner / guest）各 200 轮并发，
`-race` 干净，**零串档**
- build / vet / go test ./...（62 ok / 0 fail）/ -race 全绿
## 未变的约束
档位与主体策略**只能收窄**：`CheckToolFor` 内部先跑全局策略，
所以父的黑名单对子依然有效，子无法提权。
|
2026-10-31 07:24:03 +08:00 |
|
|
|
4af07d08fe
|
fix(memory,llm): L2 预填充并入召回主路 + 回退换 provider 时换 model（视觉失效真因）
## 1. L2（冷上下文）预填充此前只走「注入文本」，等于没有
设计：prune 与 recall 是一对 —— 工具声明 ContextPolicy=prune + RecallPolicy=auto
时，工具输出既触发裁剪、也触发预填充（memoryPass → recallTextFor）。
但 L2 那一路只写在 buildSystemPrompt 里，query 用的是**注入文本**；
QQ 注入的是「来自「X」的私聊消息(message_id=…)，先用 qq_get_message 取正文」，
与用户真正说的话毫无相似度 ⇒ 冷上下文预填充恒为空。
（现场：头天晚上讲的冷笑话，第二天早上完全唤不回；14 小时里
memory recall (input…) 只有 5 次、且 query 是元信息。）
改法：把 L2 检索并入 buildMemoryContext —— 输入路用输入文本、工具路用工具正文，
两条路共用同一次召回与预算；buildSystemPrompt 里那份重复注入删掉。
中断消息仍然 NoMemory + RecallPolicy=none（不裁剪、不召回、不进记忆），
这是设计要求，未改动。
## 2. 回退换 provider 时必须换 model（视觉失效的真因）
现场日志：
deepseek 402 Insufficient Balance
→ 回退 llmsproxy，但 req 仍带 model=「deepseek-flash」
→ llmsproxy 403 model_not_allowed
→ llmsproxy 被整源标记 unavailable（冷却）
→ 视觉回退 resolveModalFallback 跳过它 ⇒「配置了视觉却说没有视觉」
两处修正：
· 每个 provider 用自己的 model 发请求（model 是 provider 的属性）
· 403 区分「模型不被该 key 允许」与「凭证失效」：前者只否一个 model，
provider 仍可用于其他 model 与视觉回退
判据：internal/agent/core/provider_model_fallback_test.go
|
2026-10-27 11:49:26 +08:00 |
|
|
|
55fa2685ae
|
feat(security,device): security 成为独立内核模块（闸门+策略+限式），device 接管内置工具路由
security（新模块 internal/kernelmod/security）
- 凭据闸门：出向拦截成 @{别名}、入向清洗、执行前回填（internal/security/{gate,runtime}.go）
- 工具黑白名单 + 沙箱（读写根、网络、.. 逃逸）：internal/security/policy.go
- 敏感词过滤 + 提示词注入预警（Finding 不带原文）：internal/security/content.go
- 按主体授权（hard-private 对非内部主体永久拒绝）：internal/security/principal.go
- 插件命名限式（可选档位，插件声明/内核执行，只能收窄）：internal/security/profile.go
- 启动装配从 cmd/homed 迁入模块；启动顺序判据改盯真实装配点
device（新模块）
- 正式内核模块，Provides FacDevice，KernelState.Device
- 内置工具路由表下沉到 internal/toolroute（避免 core↔kernelboot 环），
device 保留对外入口；agent 未挂载时退化本地 switch
- Agent 侧只留 api.ToolHost/DeviceSurface 适配层
SDK
- InjectOptions.SecurityProfile：插件按 inputch 声明本轮安全档位（可选）
- InjectOptions.TurnHint：插件注入**本轮事实**，内核以独立 system 消息注入，
不混进用户正文（人设负责怎么说话，TurnHint 只放这一轮成立的事实）
- FacilitySecurity / FacilityDevice
提示词
- 内核自带 prompt/skill/工具返回全面英文化（中文提示会让模型行为漂移）
- 机制解释下沉到 4 个内置 skill（memory/output/tool-order/plugins），
skill 描述压到 80 runes 内（原来 94–108 全被索引截断）
- 默认人格模板英文化；[Voice] 段删除，规则并入 persona 块（单一段落）
- 历史记忆工具改名 coldcontext_query/commit，图记忆语义改称 stable memory
修复
- tracker: exec mount → unix.Mount（降权运行 + AmbientCapabilities 下才能挂）、
区分 EPERM 与不支持；启动日志说明后果与恢复方式
- healthcheck_kernel 输出瘦身：status.Tools 只给摘要（原 98,989 tokens/151% 预算）
- plugin_list 描述讲清 auto_start（按需）与 alive（此刻是否在跑），
明确不能由 alive=false 推断能力不存在
- pluginmgr/webui 去掉写死的 /home/newqqagent 回退路径（env → pluginDir 反推 → 报错）
- lua: 盘上适配器与内置版本不一致且无基线时响亮告警（deepseek 流式丢失
tool_calls 导致'模型不调工具'的真因）
测试：go build ./... 通过；go test ./... 60 包全绿
|
2026-10-26 20:55:25 +08:00 |
|
