[Feature request] 插件权限声明（Plugin Permission Manifest）：让"装插件=装可执行代码"这件事变得显式、可审查、可授权

[truelove-dreamer]

建议分类：Ideas
环境：DeepSeek Harness 0.1.0-rc.6

问题

DSH 的口号是 "Everything is a Plugin"，但插件 = 在 harness 进程内执行的全权限代码：能读凭据、发网络、起子进程、改配置。目前的防线只有两道：

1. 安装前：社区工具（如 dsh-plugin-vetting）做静态启发式扫描——但它没有足够置信度去拦停，只能当绊线（"误伤比漏检更危险"）；
2. 安装后：dsh plugin add 无签名、无来源校验、无权限边界——插件一旦装上，它的所有行为都在进程内、无约束。

结果："装插件"和"装可执行代码"之间没有一道用户能看懂、能决策的闸。用户只能靠"信不信任这个作者"来赌。

提案：插件权限声明（manifest）

插件在 package.json（或专用文件）里声明它需要的权限，harness 在加载前展示给用户、由用户授权：

{
  "dsh": {
    "bundle": { "patch": "./cordis.patch.yml" },
    "permissions": {
      "network": { "fetch": true, "socket": false },      // 能 fetch 不能开 socket
      "process": { "child_process": false },               // 不能起子进程
      "filesystem": { "roots": ["./data"] },               // 只能读写工作区 ./data
      "env": { "read": ["DEEPSEEK_API_KEY"] }              // 能读哪些环境变量
    }
  }
}

加载前展示（类似浏览器扩展的权限提示）：

• 用户 dsh plugin --profile web add <pkg> 时，harness 解析出权限清单并展示："该插件将获得：网络 fetch、读取 DEEPSEEK_API_KEY、无子进程权限——是否继续？"
• 支持 --yes 跳过、profile 级"记住授权"、以及"拒绝即不加载"。

为什么这个方案可行（相对其它方案的取舍）

方案	评价
权限声明（本提案）	✅ 声明是静态的、可审查的（与 vetting 扫描互补）；授权发生在加载前，用户可决策；实现是 loader 层的钩子（dsh plugin add 解析 manifest + 确认交互）
运行时 hook 拦截插件进程内 exec/fetch/eval	⚠️ 进程内 hook 是软闸，插件先抓原始引用即可绕过；且补丁顺序依赖加载时序；误伤全局工具的风险高
受限执行环境（VM/worker 跑插件）	✅ 最彻底，但架构改动最大（插件运行模型从"进程内 import"变为"隔离环境 RPC"），不是短期能落地的

权限声明是最小、最快、可叠加的一步：即使没有运行时强制，光是"加载前展示 + 用户知情授权"就能拦住大部分"顺手装上没细看"的情况；将来若做受限执行环境，声明的权限清单可以直接变成环境的授权边界。

需要讨论的点

1. 权限粒度：按上面示例的四类（network / process / filesystem / env）够吗？还是需要更细（如按域名白名单、按命令模式）？
2. 强制 vs 告知：v1 是"展示 + 知情授权"（不强制的软闸），还是加载时强制拒绝未声明权限？（强制的落点：loader 在 apply 前给插件一个受限的 ctx 代理？）
3. 与现有机制的关系：dsh.bundle manifest 已有 cordis.patch.yml 机制；权限声明是扩展它还是独立字段？
4. 升级路径：已有插件没有权限声明，默认策略是"视为需要全部权限 + 提示"还是"拒绝加载"？（建议前者，避免破坏现有生态）

关联

• 插件安全审计：dsh-plugin-vetting（静态绊线）——权限声明可让扫描从"猜插件要什么"变成"核对插件声明了什么"，直接降低误报率；
• 社区手册 dsh-handbook 第 13 章"插件安全审计清单"第 1 条（插件来源可信？dsh plugin add 无签名/来源校验）；
• 官方 CONTRIBUTING 目前不收外部 PR，故以 feature request 形式提交本提案。

期望

官方评估后哪怕只做"v1 = 加载前展示权限清单 + 用户确认"，也是对"插件=全权限代码"现状的实质性改善。愿意的话我可以基于 dsh-plugin-vetting 的扫描结果做一版"权限清单推断原型"作为参考实现。

[LLM-X-Factorer]

补一组“权限声明为什么需要在安装/激活前可见”的实际插件实验。这里不是 sandbox bypass：插件本来就是 Harness 宿主内的受信任代码，问题是用户在安装时看不到这次信任和配置权限变化。

实验使用一个无网络、无凭据、无模型请求的最小 bundle。安装后，它作为 profile bundle 参与配置组合，并在宿主 boot 阶段执行。

配置项	安装前	安装后
sandbox policy	workspace-write	danger-full-access
approval policy	ask	never

插件还在任何模型或工具请求发生前，以 exclusive create 写入一个由测试指定、位于所选 workspace 外的 marker。这证明它执行于模型侧 sandbox/approval 之前，权限来自 Host 进程本身。

dsh plugin add 展示了新增依赖，但没有展示上述 permission/config diff；这些变化只能在后续 --dump-config 中看到。

因此我建议 v1 不要把 manifest 描述成强制安全隔离，而应先落实两个可验证义务：

1. 安装前明确说明“插件将作为 Host 代码运行”，展示来源、解析版本与完整性信息；
2. 激活前预览安全敏感配置的新增、替换和删除，至少覆盖 sandbox、approval、credentials、telemetry 与 filesystem browse，并要求明确确认。

未来若增加真正的受限执行环境，permission manifest 可以成为强制授权输入；在此之前，它首先解决的是知情安装和可审查配置变化。

[liuwenji007]

赞同楼主把问题收成「装前知情 + 可审查的配置变化」，也赞同 v1 不要把 Manifest 说成沙箱。

补充一层工程分工，避免「有声明就等于安全」：

层	回答的问题	谁负责
声明（Manifest）	作者说自己需要什么	插件作者 / 未来宿主展示
检出（代码侧事实）	源码里能证明碰了什么，证据在源码哪一行	静态扫描（安装前扫描，可以复核）
策略 / 背书	拦不拦、推不推、谁审过	市场 / 用户 / 具名审阅

我们做的是第二层：dsh-trust-check。装前对解压目录：

npx dsh-trust-check --dir ./extracted-plugin --json

只产出关于能力方面、 注入层、来源、是否有安装脚本等可复核事实，不做「安全/可信」的背书；clear 只表示这次静态扫描未检出。若官方或社区后续定 Manifest 字段，愿意把稳定的 capabilities / redLines / facts[] 对齐进去，我们继续只做事实层的披露。