|
|
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 |
|
|
|
59f7001932
|
fix(security): 工具输出与参数会原样写进日志 —— 落盘前脱敏
## 缺陷
两处日志把工具内容原样打印，没有经过 security.Replace：
task.go:1038 log.Printf("[agent] tool %s result: %s", ..., truncateStr(result, 100))
task.go:967 log.Printf("[agent] tool %s raw_arguments: %s", ..., truncateStr(tc.RawArguments, 300))
实测场景：enc_shell 跑 curl 拿到 200，响应体里带着上游 key 的完整值
（`{"key":"sk-..."}`），这一行直接写进 /home/newqqagent/log/homed_*.log。
## 为什么日志泄漏比上下文泄漏更严重
模型上下文 短期——一轮结束就不再发送
日志 长期——每天一个文件、从不自动清理，systemd journal 另存一份，
排查问题时还会被贴进 issue
一次落盘就是永久泄漏。凭据轮换前，任何拿到日志的人都能直接用。
## 改动
· 新增 scrubForLog(text, where)：唯一入口，空安全（Global()==nil 时原样返回）
· 两处日志调用点都改为先 scrubForLog 再落盘
· 拦截本身记一笔（只记模式与长度，不记原文），便于事后发现"哪个工具常吐凭据"
## 判据（4 条）
· 明文被换成别名（真 Store，不用 mock）
· 普通文本不被改动（不误伤）
· Global() 为 nil 时不 panic（安全模块未启用是常态）
· **接线**：两处调用点确实走了 scrubForLog（只测函数不测接线会漏掉原缺陷）
变异：scrubForLog 直接返回原文 → 咬；工具结果日志去掉 scrubForLog → 咬。
|
2026-10-18 13:20:54 +08:00 |
|
