工作区信任扩展指南
什么是工作区信任?
工作区信任是一项功能,旨在解决用户在 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 子句上下文和上下文键isWorkspaceTrusted
来完成。即使命令未在 UI 中显示,它仍然可以被调用,因此您应该根据上面扩展代码中的 API 阻止执行或不注册命令。
配置(设置)
首先,您应该审查您的设置以确定它们是否需要考虑信任。如上所述,工作区可能会为您的扩展使用的设置定义一个值,该值对使用有害。如果您识别出易受攻击的设置,则应为supported
属性使用'limited'
,并在restrictedConfigurations
数组中列出设置 ID。
当您将设置 ID 添加到restrictedConfigurations
数组时,VS Code 将仅在受限模式下返回设置的用户定义值。然后您的扩展不需要进行任何额外的代码更改来处理设置。当授予信任时,除了工作区信任事件之外,还将触发配置更改事件。
调试扩展
VS Code 将阻止在受限模式下进行调试。因此,调试扩展通常不需要信任,并且应为supported
属性选择true
。但是,如果您的扩展提供了不属于内置调试流的额外功能、命令或设置,则应使用'limited'
并遵循上述指导。
任务提供程序
与调试类似,VS Code 会阻止在受限模式下运行任务。如果您的扩展提供了不属于内置任务流的额外功能、命令或设置,则应使用'limited'
并遵循上述指导。否则,您可以指定supported: true
。
测试工作区信任
有关启用和配置工作区信任的详细信息,请参阅工作区信任用户指南。