Plugin Marketplace 的发现与信任
区分目录、安装、运行时发现、启用状态与插件根信任
本页解决的问题
先给结论「Plugin Marketplace 的发现与信任」要解决的关键问题是什么?
区分目录、安装、运行时发现、启用状态与插件根信任
让这个结论先证明自己值得留下。 把这一页当成决策工具,而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果,以及一个能改变你判断的失败上。
写下一个问题:试完这个方法后,你能用什么证据回答它?
结论听起来很完整,却没有检查最关键的假设。
Marketplace:发现、安装、执行分层
目录能展示插件,安装器能复制或克隆插件,运行时还要判断启用状态与信任。把三层拆开,才能看清插件生态的真实安全边界。
课程目标
还原发现链
解释索引优先、文件系统回退、manifest 解析与来源优先级。
分开四种状态
区分可发现、已安装、已启用、受信任,避免用一个「已安装」覆盖全部语义。
画出执行边界
判断 skill、agent、hook、MCP 与 script 在未信任状态下的处理差异。
插件从目录走向运行时
Marketplace 与 Plugin 的真实结构
目录负责「有哪些」
marketplace-root/
├── .grok-plugin/
│ ├── marketplace.json
│ └── plugin-index.json
├── plugins/
│ └── sample-plugin/
└── default-skills/扫描器先读索引;缺失或无效时扫描 plugins/*/。default-skills 可作为虚拟插件加入结果。
插件负责「包含什么」
sample-plugin/
├── plugin.json
├── skills/*/SKILL.md
├── commands/
├── agents/
├── hooks/hooks.json
├── .mcp.json
└── scripts/plugin.json 是首选 manifest,.grok-plugin/plugin.json 与 .claude-plugin/plugin.json 是后备位置。PluginManifest 可覆盖 skills、commands、agents、hooks、MCP 与 LSP 路径;解析后还要验证路径仍包含在插件根目录内。
两条发现链各司其职
--plugin-dir最高来源优先级
.grok/plugins兼容 .claude
$GROK_HOME/plugins已安装插件
git / local 来源
[plugins].paths位置影响信任
关键区分:xai-grok-plugin-marketplace 负责目录、扫描和安装;xai-grok-agent::plugins 负责运行时发现、去重、名称冲突、启用与信任。Marketplace 中出现一条记录,不代表组件立即执行。
从可见到可执行的三道门
来源与路径
MarketplaceRelativePath 拒绝绝对路径、父目录穿越和越界 join。远程条目可用 git ref 或 SHA 定位内容。
启用状态
发现配置维护 enabled 与 disabled。项目或用户范围默认加入 disabled 列表,CLI override 与 config path 默认加入 enabled,用户可显式调整。
执行信任
项目插件按 canonical plugin root 授权,粒度是单个插件根。信任记录写入 ~/.grok/trusted-plugins。
未信任插件的组件矩阵
路径解析失败视为未信任
match dunce::canonicalize(plugin_root) {
Ok(path) => self.trusted.contains(&path),
Err(_) => false,
}来源影响初始判断
CLI override 与用户范围在源码中标记为 trusted;项目范围要求显式信任;config path 位于用户 home 下时可自动信任,其他位置仍需授权。
crates/codegen/xai-grok-agent/src/plugins/trust.rs · discovery.rs安装器保留来源,目录不承诺规模
安装记录可追溯
本地 Marketplace 通过 managed install storage 安装;远程条目通过 Git URL、ref、SHA 与 subdir 定位。InstallRegistry 写入 MarketplaceProvenance。
源码证明机制,不证明生态规模
当前代码能够证明官方源常量、多个来源、目录索引、搜索和安装流程。它无法单独证明插件数量、活跃作者、审核覆盖率或增长速度,本页不作这些推断。
xai-grok-plugin-marketplace/src/lib.rs · types.rs课堂练习:为插件画威胁模型
提交物
插件骨架与威胁表
- 建立一个含 skill、hook 与 MCP 配置的最小插件目录,写出 manifest。
- 建立 Marketplace 索引项,并说明索引缺失时文件系统如何回退。
- 列出可发现、已安装、已启用、受信任四个状态,画出允许的转换。
- 设计三个攻击:路径穿越、恶意项目 Hook、同名插件抢占,逐项找到源码护栏。
- 指出一个剩余风险,并给出安装前审阅、SHA 固定或最小权限方案。
插件系统的核心价值由能力面与信任面共同决定。目录解决发现,安装器解决落盘,运行时信任门决定哪些内容可以进入执行链。
源码快照说明:本页依据本地 grok-build-main 的 xai-grok-plugin-marketplace 与 xai-grok-agent::plugins 整理。目录树合并了源码默认约定,用于教学表达;来源优先级、路径约束、启用配置和信任行为保持源码语义。
「Marketplace: 发现、安装、执行分层」里的风险边界在哪里
「目录能展示插件,安装器能复制或克隆插件,运行时还要判断启用状态与信任。把三层拆开,才能看清插件生态的真实安全边界」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是:模型即使判断失误,系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「判断 skill、agent、hook、MCP 与 script 在未信任状态下的处理差异」涉及的流程中,要分别检查用户能要求什么、模型能建议什么、工具实际允许什么,以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令,不能因为它们看起来像说明就自动提升权限。
- 建立一个含 skill、hook 与 MCP 配置的最小插件目录,写出 manifest
- 建立 Marketplace 索引项,并说明索引缺失时文件系统如何回退
- 列出可发现、已安装、已启用、受信任四个状态,画出允许的转换
安全设计必须包含失败和恢复
结合「源码快照说明: 本页依据本地 grok-build-main 的 xai-grok-plugin-marketplace 与 xai-grok-agent::plugins 整理。目录树合并了源码默认约定,用于教学表达;来源优先级、路径约束、启用配置和信任行为保持源码语义」做一次反向演练:加入错误输入、缺失凭证或迟迟不到的审批,确认系统会拒绝、暂停并留下可追踪信息,而不是继续执行到底。
从「Marketplace: 发现、安装、执行分层」走到「还原发现链」
「Marketplace: 发现、安装、执行分层」先把问题落在「目录能展示插件,安装器能复制或克隆插件,运行时还要判断启用状态与信任。把三层拆开,才能看清插件生态的真实安全边界」上;到了「还原发现链」,讨论继续推进到「解释索引优先、文件系统回退、manifest 解析与来源优先级」。两段连起来,重点就不只是记住一个结论,而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时,把“模型想做什么”和“系统允许做什么”分开,逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「Marketplace: 发现、安装、执行分层」:目录能展示插件,安装器能复制或克隆插件,运行时还要判断启用状态与信任。把三层拆开,才能看清插件生态的真实安全边界
- 「还原发现链」:解释索引优先、文件系统回退、manifest 解析与来源优先级
- 「最后的要点」:指出一个剩余风险,并给出安装前审阅、SHA 固定或最小权限方案
最后的「最后的要点」把讨论落到「指出一个剩余风险,并给出安装前审阅、SHA 固定或最小权限方案」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。
读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。
还没有这篇文章的讨论。