工作区信任

2021年7月6日，作者：Chris Dias，@chrisdias

我能相信自己吗？这是自1.57更新以来，许多Visual Studio Code用户面临的生存问题。

虽然我们无法为您回答这个问题，但我们可以告诉您更多关于我们为何引入工作区信任概念的原因。

但首先，一点背景。

猫和键盘，以及坏苹果

互联网充满了快乐的事物，比如猫在键盘上打字的视频。

对于开发者来说，它还充满了由善良的人们构建的工具、包和开源项目，他们希望帮助你解决你一直在努力解决的问题。像VS Code这样的开发工具集成了包管理器、代码检查器、任务运行器、打包工具等，以提供愉快的体验，利用不断发展的社区中最新和最伟大的进步的力量。

然而，这个丰富的生态系统所提供的生产力往往是我们对开发机器提供的广泛访问的结果。再加上快速的演变和病毒式的分享与消费，开发者工具成为了一个有吸引力的攻击目标，特别是考虑到攻击者可以利用我们的机器进一步传播攻击（例如，通过存储在开发者机器上的认证令牌，甚至通过开发者编写的软件）。

作为一名开发者是有回报的，但这也是一项有风险的工作。为了为一个项目做出贡献，你本质上需要信任其作者，因为诸如运行npm install或make、构建Java或C#项目、自动化测试或调试等活动，都意味着项目中的代码正在你的计算机上执行。

我们的目标是通过工作区信任功能找到正确的平衡点，既要防止少数“坏苹果”破坏大家的体验，又要继续确保我们能够拥有所有让开发变得如此有趣的美好事物。

嘿，它只是一个编辑器，对吧？

是的，VS Code 是一个编辑器。然而，像大多数现代编辑器一样，它能够代表您从工作区运行代码，以提供更丰富的开发体验。

运行和调试代码是一个明显的例子。可能不太明显的代码执行可能是preLaunchTask，它在启动应用程序之前运行，并且可以运行一个构建，该构建有一个额外的任务执行与构建无关的任意代码。那个窃取你加密钱包私钥的npm模块呢？只需进行简单的编辑，恶意linter就会从node_modules文件夹加载，而不是全局安装的那个。即使是阅读代码也可能是欺骗性的，攻击者可以使用Unicode技巧在显而易见的地方隐藏恶意代码。见鬼，你甚至不需要打开任何源代码就能被控制。

这里的意图不是要吓跑你远离所有伟大的工具（包括VS Code），也不是要让你改变职业。它是为了提高意识，当你从互联网上下载由你没有任何信任关系的个人或组织编写的代码时，存在许多攻击机会。

打地鼠

在上述所有场景中，工具都按照设计的方式工作，并且在非恶意的代码库中，它们非常高效。设置一个preLaunchTask在调试前构建应用程序是一个很好的时间节省方法，因为你不需要在每次更改后从终端手动构建它。Linters 高度可定制，以支持每个团队偏好的编码指南和风格（是的，制表符 vs. 空格）。预提交钩子让你可以检查是否忘记了某些东西，或者确保在提交前运行测试。

现在，你不太可能同时遭受所有这些攻击。事实上，目前还没有通过VS Code进行的攻击，因为有一个由专家组成的强大社区，他们在新机会出现时让我们意识到。在Workspace Trust之前，我们的方法是在漏洞点通过本地化的权限提示来解决每个场景。

例如，Jupyter 扩展警告用户，当你在 Notebook 中打开可视化工具时，嵌入的 JavaScript 可能会运行：

ESLint漏洞是一个棘手的问题，因为它在工作区加载时运行（这是我们的第一个模态对话框）。

事实证明，这是一场必败的战斗。用户会被多个（且略有不同的）权限提示打断，这些提示并不适用于整个工作区。我相信你、你、你、你，不是你，还有你，但仅限于星期二。对我们来说，这就像一场不断的打地鼠游戏，每当一个新的漏洞暴露时，就需要通过另一个提示来修复它。

因此，我们在构建VS Code时遵循的一个模式是，查看工具和扩展中哪些体验被类似但不一致地实现，并看看我们是否能够将其纳入核心。信任提示遵循了这一模式，因此我们决定构建一个工具和扩展都可以利用的体验和API，希望带来更清晰的用户体验。

信任

现在你已经了解了代码可以在你不知情的情况下运行的多种方式，希望你对我们为什么一开始就问这个问题有了更好的理解。

我们特别询问您是否信任此工作区的作者，因为VS Code无法判断代码是否恶意（嘿，我们只知道1和0），它来自哪里，您是否打算为项目做出贡献等。

另一方面，你很聪明，你知道代码的来源：你（好的），你的公司（可能没问题），你的朋友Kai（看情况），或者互联网上的某个陌生人（绝对不行）。

这些知识有助于使工具变得更智能。如果您信任作者，那就太好了！工具和扩展可以自由地执行它们的任务并提供神奇的体验，我们不会再打扰您。

如果不这样做，你就是在告诉我们小心VS Code，不要执行任何代码。这就是我们所说的受限模式，在这种模式下，潜在有害的功能被禁用，以便你可以更安全地浏览代码，并最终做出明智的决定。

但是那个对话框！

我们理解您，模态对话框相当大，并且每次打开新文件夹时都会弹出，除非您采取行动进行配置。

我们并没有一开始就采用这个设计。我们查看了ESLint模态对话框的传奇，并问自己是否可以通过视觉提示和尽可能延迟的单一通知提示来提供非阻塞的体验。我们希望不引人注目，以受限模式启动（而您几乎不会注意到），并在最后一刻提示信任。

我们引入了一种“被动”的信任通知，您可以告诉我们是否信任工作区。我们尝试了各种UI处理方式来表明工作区不受信任，包括增强设置齿轮图标和引入新的安全图标。

如果您使用Insiders版本，您将获得VS Code中新体验的最新迭代，就像我们正在讨论的工作区信任一样。Insiders每天发布，我们用它来构建VS Code。

这个想法是让用户（你！）可以根据自己的条件决定何时授予或拒绝工作区的信任。当工具或扩展真正需要访问权限时，我们才会弹出一个通知，询问你是否信任该工作区：

现在，我相信你们中的许多人都会同意，VS Code 遭受了我们称之为“通知疲劳”的问题（我保证我们正在努力解决 😊）。在我们的测试中，我们发现人们只是忽略了通知。用户没有看到齿轮上的通知，甚至没有看到新的安全图标。使用数据显示，通过被动通知授予信任的比率非常低。在用户研究中，我们看到人们花费所有时间认为他们弄坏了什么东西，然后花费时间进行故障排除，试图回到他们预期的状态。

我们本打算尽可能低调和延迟，但现实是，在受限模式下，产品感觉像是出了问题，人们认为这是他们的错。这对我们双方来说都不是一个好地方。

让你掌控一切

决定信任一个文件夹对VS Code的功能有着根本性的影响，因此经过所有研究后，我们决定在您尝试打开文件夹时立即询问信任问题。由于模态对话框具有干扰性，我们尝试通过使对话框功能强大来平衡这一点，以便您可以回答几个问题，最终在日常工作中看到提示的频率会大大减少。

通过我们自己的实践以及与其他开发者的访谈，我们发现人们通常有一个主要文件夹，他们将所有源代码放在其中并认为它是可信的。因此，我们增加了直接从对话框中信任父文件夹的功能。您可以一键信任它及其所有子文件夹，之后您将不再看到信任提示。

工作区信任编辑器

工作区信任编辑器为您提供了额外的控制权，让您能够更好地管理信任的内容，并且将在1.58版本中更新，以便更轻松地配置该功能以满足您的需求。

因为你可以自定义行为，所以有很多方法可以进入信任编辑器 😊。点击受限模式状态栏消息、受限模式横幅中的管理链接、齿轮菜单，或者打开命令面板（F1）并使用工作区：管理工作区信任命令。

从工作区信任编辑器中，您可以信任当前文件夹、父文件夹（以及所有子文件夹），以及机器上的任何文件夹。

您还可以快速跳转到所有工作区信任设置，以微调体验。

我们如何使用工作区信任

没有人喜欢用牙线清洁牙齿，但我们还是这样做，因为我们知道这是正确的事情。没有人愿意考虑安全问题，但我们也知道这是正确的事情。通过定制体验，您可以在保护自己免受开发中固有威胁的同时，保持开发体验的愉快（有趣的牙线清洁？！？）。

VS Code 团队中的大多数人一开始都会使用一个顶级文件夹，他们在其中处理他们信任的源代码。例如，在我的 Mac 上，我将从 GitHub 上的 Microsoft 组织拉取的所有源代码放入我的 ~/src 文件夹中。我将 ~/src 指定为受信任的文件夹，其下的所有内容都默认受信任。当我打开 ~/src/vscode 或 ~src/vscode-docker 等时，它们会以完全信任的方式打开，因为我信任我的组织编写和使用的代码。

我有一个单独的文件夹叫做~/scratch（“scratchpad”的缩写，你可以随意命名），我把所有其他内容都放在这里，并默认认为它是不可信的。然后，我会逐个文件夹做出信任决定。

为了简化我的工作流程，我将"security.workspace.trust.startupPrompt"设置设为"never"。

通过此设置，我不会被模态对话框提示，工作区将直接在受限模式下打开。我已经决定~src/scratch文件夹是不可信的，因此每次打开子文件夹时无需提示我。如果我决定信任我正在阅读或编写的代码，我可以通过两次快速点击在文件夹上启用它（VS Code顶部的受限模式通知，然后点击信任按钮）。

在我的Windows机器上，情况有点更有趣。我通常在运行于Windows Subsystem for Linux (WSL)上的Ubuntu镜像中工作，使用WSL扩展。我信任Linux上的~/src文件夹，也信任Windows端的d:\src文件夹。

团队中的一些人更进一步，关闭了顶部的受限模式横幅（"security.workspace.trust.banner": "never"），只留下状态栏通知。对我来说，这太过分了，顶部的横幅让我保持诚实，并帮助提醒我在从互联网拉取内容时要保持警惕。

开源是极好的

我们知道VS Code是您用来完成“真正”工作的工具，我们引入的任何速度障碍或路障只会减慢您构建和推出下一个独角兽的速度。许多人抽出时间在Twitter、Reddit和问题中联系我们，我们感谢您的坦诚反馈。根据您的意见，我们在1.58版本中进行了许多修复和改进，并期待继续对话。

展望未来，我们希望帮助扩展作者避免任意代码执行，并在受限模式下提供更多功能。我们的路线图记录了我们与Visual Studio Marketplace团队合作的工作，旨在为扩展生态系统带来额外的安全性（我们称之为“可信扩展”），包括已验证的发布者、签名和特定平台的扩展。简而言之，您可以将工作区信任视为帮助好的扩展做出好的决策。可信扩展将帮助您免受不良扩展的侵害。

在公开环境中构建VS Code的好处之一是社区可以帮助我们创造最佳体验。因此，请告诉我们如何改进流程，帮助您在尽可能不打扰的情况下保持安全。请在现有问题上（礼貌地！）评论，提交新问题，或在推特上@code联系我们，我们正在倾听！

谢谢，

克里斯和VS Code团队

快乐编程（安全地）！