工作区信任扩展指南
什么是工作区信任?
工作区信任 是一项由用户在 VS Code 中打开工作区时,与意外代码执行相关的安全风险驱动的功能。例如,假设一个语言扩展为了提供功能,可能会执行来自当前加载的工作区的代码。在这种情况下,用户应该信任工作区的内容不是恶意的。“工作区信任”将此决策集中在 VS Code 中,并支持受限模式,以防止自动代码执行,从而使扩展作者不必自己处理此基础结构。VS Code 提供静态声明和 API 支持,以快速引导扩展,而无需跨扩展复制代码。
入门
静态声明
在你的扩展的 package.json
中,VS Code 支持以下新的 capabilities
属性 untrustedWorkspaces
capabilities:
untrustedWorkspaces:
{ supported: true } |
{ supported: false, description: string } |
{ supported: 'limited', description: string, restrictedConfigurations?: string[] }
对于 supported
属性,接受以下值
true
- 该扩展在受限模式下完全受支持,因为它不需要工作区信任来执行任何功能。它将像以前一样启用。false
- 该扩展在受限模式下不受支持,因为它在没有工作区信任的情况下无法运行。它将保持禁用状态,直到授予工作区信任为止。'limited'
- 该扩展的某些功能在受限模式下受支持。信任敏感的功能应禁用,直到授予工作区信任为止。扩展可以使用 VS Code API 来隐藏或禁用这些功能。工作区设置可以使用restrictedConfigurations
属性自动通过信任进行门控。
对于 description
属性,必须提供信任原因的描述,以帮助用户理解哪些功能将被禁用,或者在授予或拒绝工作区信任之前他们应该查看哪些内容。如果 supported
设置为 true
,则忽略此属性。
description
属性的值应添加到 package.nls.json
中,然后在 package.json
文件中引用,以获得本地化支持。
restrictedConfigurations
属性接受配置设置 ID 的数组。对于列出的设置,当在不受信任的工作区的受限模式下时,扩展将不会获得工作区定义的值。
如何支持受限模式?
为了帮助扩展作者理解工作区信任的范围以及哪些类型的功能在受限模式下是安全的,以下是一些需要考虑的问题。
我的扩展是否具有主入口点?
如果扩展没有 main
入口点(例如主题和语言语法),则该扩展不需要工作区信任。扩展作者无需对此类扩展采取任何操作,因为无论工作区是否受信任,它们都将继续独立运行。
我的扩展是否依赖于打开的工作区中的文件来提供功能?
这可能意味着可以由工作区设置的设置,或者工作区中的实际代码。如果扩展从未使用过工作区的任何内容,则可能不需要信任。否则,请查看其他问题。
我的扩展是否将工作区的任何内容视为代码?
最常见的例子是使用项目的工作区依赖项,例如存储在本地工作区中的 Node.js 模块。恶意工作区可能会签入模块的受损版本。因此,这对用户和扩展来说都是安全风险。此外,扩展可能依赖于控制扩展或其他模块行为的 JavaScript 或其他配置文件。还有许多其他示例,例如执行打开的代码文件以确定其用于错误报告的输出。
我的扩展是否使用确定可以在工作区中定义的代码执行的设置?
你的扩展可能会使用设置值作为扩展执行的 CLI 的标志。如果这些设置被恶意工作区覆盖,它们可能会被用作针对你的扩展的攻击媒介。另一方面,如果设置的值仅用于检测某些条件,则它可能不是安全风险,并且不需要工作区信任。例如,扩展可能会检查首选 shell 设置的值是 bash
还是 pwsh
,以确定要显示哪些文档。配置(设置) 部分在下面提供了有关设置的指南,以帮助你找到扩展的最佳配置。
这不是可能需要工作区信任的案例的详尽列表。随着我们审查更多扩展,我们将更新此列表。在考虑工作区信任时,请使用此列表来考虑你的扩展可能正在执行的类似行为。
如果我不对我的扩展进行更改怎么办?
如上所述,未向其 package.json
贡献任何内容的扩展将被视为不支持工作区信任。当工作区处于受限模式时,它将被禁用,并且用户将收到通知,告知某些扩展由于工作区信任而无法工作。此措施是用户最注重安全的方法。即使这是默认设置,但设置适当的值以表明作为扩展作者,你已努力保护用户和你的扩展免受恶意工作区内容的侵害,也是最佳实践。
工作区信任 API
如上所述,使用 API 的第一步是将静态声明添加到你的 package.json
中。引导的最简单方法是对 supported
属性使用 false
值。再次强调,即使你什么都不做,这也是默认行为,但它向用户发出了一个很好的信号,表明你已做出慎重的选择。在这种情况下,你的扩展无需执行任何其他操作。在授予信任之前,它不会被激活,然后你的扩展将知道它是在获得用户同意的情况下执行的。但是,如果你的扩展仅需要信任才能实现其部分功能,则这可能不是最佳选择。
对于希望根据工作区信任来门控其功能的扩展,他们应该对 supported
属性使用 'limited'
值,并且 VS Code 提供了以下 API
export namespace workspace {
/**
* When true, the user has explicitly trusted the contents of the workspace.
*/
export const isTrusted: boolean;
/**
* Event that fires when the current workspace has been trusted.
*/
export const onDidGrantWorkspaceTrust: Event<void>;
}
使用 isTrusted
属性来确定当前工作区是否受信任,并使用 onDidGrantWorkspaceTrust
事件来监听何时向工作区授予了信任。你可以使用此 API 来阻止特定的代码路径,并在工作区受信任后执行任何必要的注册。
VS Code 还公开了一个上下文键 isWorkspaceTrusted
,用于如下所述的 when
子句中。
贡献点
命令、视图或其他 UI
当用户未信任工作区时,他们将在受限模式下运行,功能有限,旨在浏览代码。你在受限模式下禁用的任何功能都应从用户处隐藏。这可以通过 when clause 上下文 和上下文键 isWorkspaceTrusted
完成。即使命令未显示在 UI 中,仍然可以调用该命令,因此你应该根据扩展代码中上面的 API 阻止执行或不注册命令。
配置(设置)
首先,你应该查看你的设置,以确定它们是否需要考虑信任。如上所述,工作区可能会为你的扩展使用的设置定义一个值,该值对使用是恶意的。如果你识别出易受攻击的设置,则应该对 supported
属性使用 'limited'
,并在 restrictedConfigurations
数组中列出设置 ID。
当你将设置 ID 添加到 restrictedConfigurations
数组时,VS Code 将仅在受限模式下返回设置的用户定义值。然后,你的扩展无需进行任何其他代码更改即可处理该设置。授予信任后,除了工作区信任事件之外,还会触发配置更改事件。
调试扩展
VS Code 将阻止在受限模式下进行调试。因此,调试扩展通常不需要请求信任,并且应为 supported
属性选择 true
。但是,如果你的扩展提供了不属于内置调试流程的其他功能、命令或设置,则应使用 'limited'
并遵循上述指南。
任务提供程序
与调试类似,VS Code 阻止在受限模式下运行任务。如果你的扩展提供了不属于内置任务流程的其他功能、命令或设置,则应使用 'limited'
并遵循上述指南。否则,你可以指定 supported: true
。
测试工作区信任
有关启用和配置工作区信任的详细信息,请参阅工作区信任用户指南。