用固定 Commit 审 DSH 插件：先查权限，再谈好不好用

这是一份可在本地复现的 DSH 插件源码审计方法。对象是 dsh-rich-tracking 的固定 Commit，而不是一个已经安装的运行实例。方法会保存来源、计算文件摘要、列出工具和路由、扫描高影响权限，再把“源码检查通过”和“运行验收未做”明确分开。

本文看点

准备一份不会漂移的输入

把权限从代码里抄出来

用几条确定性检查做本地复现

把证据分成三层

回滚也要提前写

审计结果

审计不要直接对着仓库默认分支下结论。先记录仓库地址、Commit、版本、许可证和读取时间，再保存 README、Cordis patch、host.js 以及需要分析的纯引擎文件。每个文件计算 SHA-256，报告里保留相对路径和摘要；未来重新审计时，第一步先判断输入有没有变。

本轮使用 dsh-rich -tracking 的 Commit 722106334f4c8aa34fd4144c8582e5a0cfc00387，README 标为 0.6.8，许可证为 MIT。DSH 最新可见版本是 0.1.5-alpha.1，插件 README 要求至少 0.1.2-alpha.1。版本兼容是来源信息，不是本机运行结果。

第一遍只做名词清单，不判断好坏：导出的工具、路由、文件读写、子进程、网络访问、环境变量、主目录路径、浏览器权限和会话事件。第二遍再把每项映射到用途、输入、输出、失败处理和可撤销动作。这样做比看到“安全”或“loopback”就直接盖章更稳。

本例中， README 和 patc h 指向 tracking_write、tracking_checkpoint、tracking/decision 与 loopback-fenced action route；host.js 显示 node:child_process 和 node:fs 导入。审计结论应写成“存在这些权限面，需在运行时检查其实际调用”，不能写成“发现恶意行为”，也不能写成“无风险”。

最小脚本可以验证四件事：固定文件是否存在且摘要一致；README 是否包含安装与卸载说明；patch 是否同时声明宿主与浏览器侧；host.js 是否包含预期的路由、工具和权限关键词。脚本输出 JSON，成功与失败都留下原因。它验证的是审计输入和规则，不是插件能否正常运行。

再加三类人工复核：权限是否超出功能所需，失败是否会静默吞掉错误，卸载后状态是否可恢复。对有 execFile、写配置和捕获 Git 的插件，人工要特别看参数是否固定、路径是否可控、输出是否进入模型上下文，以及敏感字段是否可能被保存。

Source layer 证明你审的是哪一版文件；bundle layer 证明打包关系、权限和入口如何连接；runtime layer 才能证明在某个 Profile、浏览器和重启顺序下，功能真正出现且行为符合预期。三层缺一不可，但不能互相冒充。

本轮的本地审计通过了 so urce 和 bundle 检查，runtime 仍是 pending。报告里的这个词很重要：它允许下一次工作从安装和重启开始，而不是让后来的人误以为所有门已经过了。

安装前保存 Profile 位置、配置摘要和 Git 状态；安装后只在临时 Profile 里试；卸载时按 README 或插件管理器的 disable 路径操作，再重启并复核内置界面。不要用删除整个 DSH 主目录的方式“清理插件”，那会把无关会话、凭据和配置一起带走。

如果插件写入会话事件或配置，回滚还要检查旧数据是否仍可读、是否有残留路由和是否需要迁移。可恢复不是一句口号，而是一串前后状态都留存的证据。

本地复现结果：固定 Commit、README、patch 和 host.js 均存在，文件摘要已记录；安装、卸载、重启和最终任务验收未执行。结论为 source_review_passed、runtime_acceptance_pending、manual_publish_only=true。

这份方法适合放进插件候选入库前的门禁，也适合开发者提交自己的证据包。它不判断某个插件最终值不值得用，而是确保“值得用”的判断有对象、有权限、有回滚、有下一步。

用东方文化看懂现代科技