尝试以扩展 VS Code 中的代理模式!

工作区信任扩展指南

什么是工作区信任?

工作区信任是一项功能,旨在解决用户在 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 contexts和上下文键isWorkspaceTrusted来完成。即使命令未在 UI 中显示,它仍然可以被调用,因此您应该根据扩展代码中上述 API 阻止执行或不注册命令。

配置(设置)

首先,您应该审查您的设置以确定它们是否需要考虑信任。如上所述,工作区可以为您的扩展使用的设置定义一个值,该值对使用有害。如果您识别出易受攻击的设置,您应该对supported属性使用'limited',并在restrictedConfigurations数组中列出设置 ID。

当您将设置 ID 添加到restrictedConfigurations数组时,VS Code 将仅在受限模式下返回用户定义的设置值。然后,您的扩展无需进行任何额外的代码更改来处理设置。授予信任后,除了工作区信任事件之外,还会触发配置更改事件。

调试扩展

VS Code 将阻止在受限模式下调试。因此,调试扩展通常不需要信任,并且应为supported属性选择true。但是,如果您的扩展提供了不属于内置调试流的附加功能、命令或设置,则应使用'limited'并遵循上述指南。

任务提供程序

与调试类似,VS Code 会阻止在受限模式下运行任务。如果您的扩展提供了不属于内置任务流的附加功能、命令或设置,则应使用'limited'并遵循上述指南。否则,您可以指定supported: true

测试工作区信任

有关启用和配置工作区信任的详细信息,请参阅工作区信任用户指南