|
|
1b8218afa9
|
fix(tools): 审计器补齐 recv/selfCalls 索引与只读白名单；标注器定位修正
## audit_parallel 的四个误判来源
**① indexMethods 没设 recv 和 selfCalls ⇒ 递归跟进空转**
`scanWritesDeep` 靠 recv 组候选键、靠 selfCalls 才知道跟进谁，缺任一个
就静默漏判。handleRestart 只调 p.stopServer/startServer 两个方法，
因此被判成"只读" —— 而 stopServer 里有 `p.server = nil`。
（我先补了闭包那条分支的 selfCalls，误以为问题在闭包上，其实是
indexMethods 整体缺字段。）
**② writePatterns 写了 ".Set(" 而 callString 收集的是方法名**
`p.sdk.Settings().Set(...)` 是三段链，callString 返回 "Settings.Set"，
永远匹配不上 ".Set("。漏判比误判更难发现：结果看着仍然合理。
→ 模式改为不带括号。
**③ looksLikeExternal 用黑名单 ⇒ 纯读标准库调用全被判"可能写"**
Marshal / ReadAll / NewRequest / NewReader 都不带写操作迹象，却被判写，
120 个工具里 119 个判成 SERIAL —— 等于工具没在工作，却**看上去在工作**
（保守方向不会引起怀疑）。
→ 改为 knownReadOnlyCalls 白名单。判定原则：**默认怀疑，明确信任** ——
写不动的东西要逐个列出来。
**④ 工具名提取打印 AST 内部结构**
`fmt.Sprintf("%v", a.Y)` 输出 `tp&{10500 10515 STRING "manage_social"}`，
名字里混着指针地址，人没法核对。
→ 改用 BasicLit.Value + 归一化去掉运行期前缀。
## annotate_parallel 的插入点定位
改文本匹配改结构体字面量这条路走了三次弯：
- 正则找"最后一个顶层字段"被嵌套 map 里的同形文本骗到，823 处重排改坏文件
- 变量前缀匹配没要求 RegisterTool( 在**同一行**，命中函数体里散落的字面量，
起点错到 switch case 中间，报错指向一处看起来完全无辜的分支
- 只按行末**净**深度判断：Parameters 写在单行时（进出同一行，净变化 0）
永远察觉不到曾进入深度 3，追踪一路跑到 1305 行才"收敛"
→ 最终按**行内峰值深度** + 记录进入深度 3 的行号判定。
## 幂等
未标注过的工具重复跑会插入第二份 ParallelSafe（duplicate field 编译错误）。
→ 加 blockHasDecl 预检。
|
2026-09-27 16:17:04 +08:00 |
|
|
|
deeda22650
|
tools: 工具并发安全审计器（audit_parallel + annotate_parallel）
两个工具，都是为了让「这个工具能不能并发」有**可复现的依据**，而不是靠人眼扫。
## tools/audit_parallel.go —— 审计
为什么需要它：正则扫 `ToolDef` 字面量**不可靠**。用它审计主仓 27 个工具时，
把 `config_set` 判成"无共享写"，而它的 handler 其实在 `p.handleSet` 里且无锁 ——
原因：RegisterTool 第三个参数是方法名/闭包，正则看不到执行体。
本工具用 go/ast 从**注册点跟进到 handler 实现**，递归 3 层（带环检测），
输出三态：SAFE / SERIAL / UNKNOWN。
★ UNKNOWN 一律不声明并发安全 —— 追不到实现就不能声称安全。
### 开发它时踩的坑（都写在代码注释里）
- **通用 HTTP 包装器**：vanblog 的 manage_social / manage_settings 全走
`p.do("GET"|"POST"|"PUT", ...)`，方法名毫无写操作迹象，纯靠名字匹配
**全判成 SAFE** —— 而它们明确含 POST/PUT。审计工具给出与代码相反的结论，
比不给结论更危险（人会信它）。改为按 HTTP 动词判定后，
统计从 72/37 变为 46/63。
- **链式调用丢方法**：`p.sdk.Settings().Set(...)` 是三段链，只看最外层只得到
"Settings"，`.Set` 整个丢失 ⇒ handleConfigure（写配置 + 启停服务）被判只读。
改为收集整条链的所有方法名。
- **变量名 ≠ 类型名**：调用点写 `p.handleRead()`，定义处是
`func (p *Plugin) handleRead()`。拿变量名去查类型索引**永远匹配不上**，
143 个工具全报 UNKNOWN。须建"变量名 → 接收者类型"索引。
- **方法接收者不是局部变量**：example 里根本没有 `p := &Plugin{}`，
p 是 Start 的接收者，局部变量索引全空。须把接收者变量名也纳入索引。
- **枚举被字符串污染**：verdict = "Serial:true" 而 report 只认三个枚举值
⇒ 全部落进 UNKNOWN，输出"共 13：UNKNOWN 13"，看着像工具没在工作。
- **作者声明必须优先**：我把"已声明"当 finding 记录后照常跑写入检测并
**覆盖** verdict，于是 plugin_install（已标 Serial:true）被判 SAFE。
## tools/annotate_parallel/ —— 标注
按 SDK 风格插入声明项：Name 在首位，声明项在末尾（Parameters 之后、
handler 之前），不打散 gofmt 对齐。
插入点必须用**括号深度 + 记录进入深度 3 的行号**定位：
- `RegisterTool( =1, ToolDef{ =2, Parameters{ =3`
- 只判 depth==2 会在 `Name:` 行就返回（那行本来就是深度 2），
插入点跑到 RegisterTool 之前，编译报 "expected 1 expression"
- 空 `properties: map[string]interface{}{}` 让深度**在同一行**进出平衡，
所以"曾触及深度 3"也不能作门控，必须记行号
- 试过用正则找"最后一个顶层字段"，被嵌套 map 里的同形文本骗到，
823 处错误重排把文件改坏 —— 文本匹配改结构体字面量就是这条路
用法：go build -o /tmp/annotate ./tools/annotate_parallel
/tmp/annotate <file> <tool:parallel|serial:说明> ...
|
2026-09-27 16:17:04 +08:00 |
|
