soft_quay/docs/review/remediation-t606-t614-review.md

整改审核:T-606 ~ T-614(Phase 1/2 审查结论的落地验证)

审查范围:f1cc730(T-606)、0945fe9(T-607)、1b7f72e(T-608)、1715729(T-609)、e9386d2(T-610)、320b83d(T-611)、0f69fa3(T-612)、20596a7(T-613)、0c1b766(T-614)。 审查视角:全栈开发工程师。 审查方式:静态代码审计——不信任任务自述,逐项核实际代码;重点核并发、耐久性、路径/DoS、签名四类高风险改动。因 WSL 无 Go,未执行测试。 日期:2026-07-18

总体判断

合理,且是真修复,不是文档层的自述。 Codex 系统性关闭了 Phase 1 与 Phase 2 审查的全部可执行结论——不仅 Phase 2 的 6 项(T-606~611),还回补了 Phase 1 遗留的三项(T-612 中央目录 DoS、T-613 断电耐久性、T-614 签名跨实现向量)。逐项核了实际代码,实现方向和落地都对。剩余的是几处诚实的残留(见末尾),不影响"整改成立"的结论。

逐项核实(代码级)

任务	对应审查项	核实结论	代码证据
T-606	Phase2 P1 + 交叉裁定"内存无界" + Codex NEW P1	成立	icon_cache.go:in-flight 去重(leader 在锁外做 disk/network,waiter 释放锁等 flight.done 或 ctx.Done(),delete(inflight)+close(done) 在成功/失败都执行,无泄漏);icon_memory.go 用 container/list LRU 按字节(32MiB)+ 条数(256)双限;fetcher 改流式 IconFetchResponse{Body,ContentLength},readFetchedIcon 先拒 ContentLength>max、再 io.ReadAll(io.LimitReader(Body,max+1))、再复检、defer Body.Close();SetItems 剪枝 shell.icons 等全套图标 map
T-607	Codex NEW P2(UI 线程投递)	成立	后台 Load/Decode 只发事件,经有界 FIFO relay 回 Gio UI goroutine 后再 ApplyEvent/ApplyIcon;SetItems 剪枝 iconRequests/iconApplied/iconFailures,迟到结果按最新请求/删除/IconRef 变化/取消阻断
T-608	Phase2 P2(sharpen)	成立	双端交互契约测试:验证 Editor/Clickable 经 Layout 更新共享 model、重排后 AppID 行身份、详情关闭上下文、500 项 viewport、controls 释放;非重复断言 ViewModel
T-609	Phase2 P4(sharpen)	成立	refilter 构造新 backing array 后原子替换(非每帧拷贝),旧 generation 跨五类 mutation 稳定
T-610	Phase2 P5	成立	双端 shell.go 拆为 header/navigation、catalog/list、detail、style 同 package 职责文件,根调用链不变
T-611	Phase2 P6	成立	symlink/非普通 cache entry fail-closed、零 fetch、不改写 entry/target,发 IconFailed/unsafe_cache + 人工 runbook;自动 quarantine 仍留威胁模型裁定
T-612	Phase1 P2(中央目录 DoS)	成立	新增 zipscan.go;ExtractFile 要求 expectedPackageSize,openAndScanArchive 在 zip.NewReader 前校验文件大小精确等于 Catalog 声明并预扫描;limits.go 加 MaxArchiveBytes(4GiB)+ MaxCentralDirectoryBytes(且校验 ≤ archive)
T-613	Phase1 P1(断电耐久性)+ Codex NEW(payload 未 sync)	成立	durability.go 抽象 fence;durability_windows.go 用 syscall.FlushFileBuffers、durability_other.go 用 directory.Sync();extractor.go 每个 payload syncFileWithFence + syncStagingTree;switcher/transaction/recovery/layout 在每次 rename、journal 替换、备份/恢复/删除后插目录 fsync 点
T-614	Phase1 P3(跨实现签名向量)	成立	canonical.go 加 validateJSONStringSurrogates(拒绝孤立高/低 surrogate、不配对);testdata/catalog/canonical-vectors.json 覆盖 reject-isolated-high/low-surrogate、mismatched-pair、negative-zero、signature-crlf/space/tab、missing/extra-padding、equivalent-object-order

重点模块判断

• T-606 并发正确性:in-flight 去重无死锁(leader 全程不持锁做 IO,waiter 只等 channel),不同 key 真并行、同 key 只拉一次、错误也清 flight。这是对我"naive check-unlock-fetch"的正确超越。
• T-613 耐久性方向正确:目录级 fsync 的平台分叉(Windows FlushFileBuffers / POSIX dir Sync)+ payload 文件 sync + journal 与 rename 之间的顺序点,正是 Phase 1 P1 建议的完整落地。fence 可注入,durability_test.go(334 行)做步骤间故障注入。
• T-612/T-614 安全闭合:包大小在解析任何 ZIP 数据前强制等于已验签 Catalog 声明;签名向量把 surrogate/base64 空白/负零/等价顺序行为冻结成跨实现测试,发布端可据此对齐。

残留与提醒(不影响"整改成立",但应记录)

R1 · T-613 的耐久性是"构造正确",真机断电验证仍未做(且 Windows 更需要)

fsync 点插得对,但真实断电保证依赖 OS/FS 履行 fsync 语义。关键:Windows 对目录句柄 FlushFileBuffers 是否真正持久化目录项,MSDN 不像 POSIX fsync(dir) 那样有明确保证。因此:

• 结论应表述为"耐久性顺序已构造正确",而非"断电安全已验证"。
• 真机/VM 断电故障注入(Phase 1 已划 T-302/T-601)在 Windows 上比 POSIX 更必要,不能因为代码已插 fsync 就跳过。

R2 · T-613 逐 payload 文件 fsync 的性能成本待真实包复核

syncFileWithFence 逐个 payload 文件调用;含数千文件的包会产生数千次 fsync,在慢盘或杀软介入下安装可能明显变慢。正确性优先的取舍成立,但阈值/策略应在 T-302 用真实包分布复核(可评估"逐文件 sync + 目录 sync"是否可优化为"批量 + staging 树 sync")。

R3 · T-606 waiter 继承 leader 的 ctx 取消(singleflight 通病,低危)

leader 的 ctx 取消会让所有 waiter(即使自身 ctx 有效)拿到取消错误。对图标是良性(重试即可),但若未来复用该模式于非幂等/高代价资源,需重新评估是否给 waiter 独立重试或 leader 交接。

结论

T-606~T-614 是一次系统性、可核实的整改:Phase 1 与 Phase 2 审查的可执行结论已全部落地并接线,实现质量与前几个阶段一致。当前无需回滚或返工。剩余的是三条已记录的残留(R1 真机断电验证、R2 fsync 性能、R3 singleflight 通病),其中 R1 是唯一需要在发布前用真实环境关闭的项,且本就属 T-302/T-601 既定范围。

声明:本报告为静态代码审计,逐项核实了实现而非任务自述;因 WSL 无 Go 未执行测试,Codex 自述双 workspace 闸门通过。R1 的真机断电语义本就需硬件级注入,不由静态审计或步骤级故障注入替代。