工作区信任扩展指南
什么是工作区信任？
工作区信任是一项由安全风险驱动的功能，这些风险与用户在 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 将在受限模式下仅返回设置的用户定义值。您的扩展 then 不需要进行任何额外的代码更改来处理设置。授予信任后，除了工作区信任事件之外，还将触发配置更改事件。
调试扩展
VS Code 将阻止在受限模式下调试。因此，调试扩展通常不需要信任，并且应该为supported属性选择true。但是，如果您的扩展提供了不属于内置调试流的附加功能、命令或设置，则应使用'limited'并遵循上述指导。
任务提供程序
与调试类似，VS Code 阻止在受限模式下运行任务。如果您的扩展提供了不属于内置任务流的附加功能、命令或设置，则应使用'limited'并遵循上述指导。否则，您可以指定supported: true。
测试工作区信任
有关启用和配置工作区信任的详细信息，请参阅工作区信任用户指南。