安装插件前的安全检查清单
用十分钟检查来源、命令、权限、凭据和回滚路径；学会区分“信息不足”和“明确风险”，再决定是否把插件交给本机与 Agent。
约 8 分钟读完
读完这篇你会
- 在十分钟内完成一次插件安装前的来源、命令、权限与回滚检查
- 分清“资料不足”“需要确认”和“明确不该继续”三种状态
- 用隔离 profile 降低陌生插件影响日常环境的风险
适用版本
Compatible with: dsh 0.1.x。这是一份用户侧的决策清单，不是安全认证，也不能替代代码审计。
为什么安装插件需要检查
插件不是单纯的界面皮肤。它可能读取文件、访问网络、调用外部程序，或让 Agent 多出一项可以主动调用的能力。风险不等于不能装；风险意味着你需要知道它在做什么，并让授权范围与需求相称。
安装前最重要的不是问“它安全吗”，而是问：它为什么需要这些能力？如果出错，我能否停止并恢复？
十分钟检查清单
1. 来源：我知道代码来自哪里吗？
- 安装命令指向的 npm 包或 GitHub 仓库是否和详情页、README 一致？
- 仓库是否公开，维护者是否能追溯？
- README 是否说明功能、配置和限制，而不只是营销语？
- 若是 fork、镜像或子目录插件，是否解释与上游的关系？
来源不清时，不要用“Star 高”替代答案。Star 可以是大仓库累计的热度，不说明当前子包的维护情况。
2. 命令：我理解即将执行什么吗？
把命令拆开看：目标 profile、来源、版本/ref、本地路径和额外 flag。尤其停下来检查以下信号：
| 信号 | 应做什么 |
|---|---|
| 要求 `curl ... | sh` 或下载后直接执行 |
| 要求关闭沙箱或广泛授权 build script | 先找出具体依赖与必要性 |
| 指向临时 URL、匿名仓库或难以复现的分支 | 要求固定版本或可追溯来源 |
| 命令与 README 不一致 | 以维护者的最新文档核实，暂停安装 |
本站兼容性检查会标出已抓取文本中的部分高风险模式。它是提醒，不是“绿灯”；没有命中也不表示所有代码已审计。
3. 权限：能力和任务相称吗？
为插件写一句“能力—理由”对应关系：
| 能力 | 合理的理由 | 需要追问的情况 |
|---|---|---|
| 读取项目文件 | 代码检索、文档分析 | 声称是主题却读取整个 home 目录 |
| 网络访问 | 调用明确的 API | 不说明域名或发送哪些数据 |
| 子进程 | 调用已知转换工具 | 任意 shell、后台常驻进程 |
| Token | 访问特定服务 | 要求把 token 写进 README、命令或仓库 |
能力多不一定不好，但每一项都应该能解释。解释不出来时，把它当成未完成的调查，而不是默认同意。
4. 凭据：token 会去哪里？
不要把 API Key、Cookie、SSH key 或生产配置粘进聊天、命令历史、README 或项目仓库。优先使用 DSH/系统提供的设置或环境变量机制，并确认：
- 插件是否会在日志里打印配置；
- token 是否只发往你预期的服务；
- 卸载后是否还留下配置或缓存；
- 能否为试用创建一个权限更小、可撤销的 token。
一旦插件要求你把长期 token 直接写进命令行，先停止；命令历史往往比你想象得更容易泄露。
5. 回滚：失败后怎么离开？
安装前先写下：插件 ID、原始命令、所在 profile、相关配置文件和卸载命令。陌生或高权限插件优先装进专门的试验 profile；验证通过再进入日常 profile。
回滚不是失败，而是正常的试用设计。可回滚让你更敢探索，也让真正的问题更容易复现。
三种结论，分别怎么做
| 结论 | 典型情况 | 下一步 |
|---|---|---|
| 可以试 | 来源、命令、权限和回滚都清楚 | 在正确 profile 做最小验证 |
| 需要确认 | 缺平台声明、文档过旧、权限理由不完整 | 阅读 README、issue，或先隔离试用 |
| 停止 | 要求秘密、关闭保护、执行不明脚本，且无法解释 | 不安装；保留链接和原因，必要时向维护者提问 |
常见问题
机审证据得分高，是否可以直接信任？
不能。高分只说明目录能验证更多事实，例如 README、安装命令、许可证或兼容性字段存在。它不能证明代码没有漏洞，也不能证明适合你的环境。
我只是装一个主题，还需要这么做吗？
检查可以更快，但不应跳过。主题通常权限较低；如果它却要求网络、文件扫描或 shell，这正是你应该停下来问“为什么”的信号。
下一步
完成检查后，用插件安装失败怎么排查中的最小验证流程完成试用。