工作区信任
2021 年 7 月 6 日，作者：Chris Dias，@chrisdias
我能信任自己吗？自从 1.57 版本更新以来，这是许多 Visual Studio Code 用户面临的存在问题。
虽然我们无法为您解答这个问题，但我们可以告诉您更多关于我们为什么引入工作区信任概念的原因。
首先，先介绍一点背景知识。
猫和键盘，以及坏苹果
互联网上充满了快乐的事情，比如猫在键盘上打字的视频。
对于开发人员来说，互联网上也充满了由善良的人们构建的工具、软件包和开源项目，他们希望帮助您解决您已经花费数小时处理的问题。像 VS Code 这样的开发工具集成了软件包管理器、代码检查器、任务运行器、打包器等，以提供愉快的体验，利用不断发展的社区中最新和最伟大的进步的力量。
然而，这个丰富的生态系统所带来的生产力往往是我们为开发机器提供的广泛访问权限的结果。再加上快速的演变和病毒式的共享和消费，开发人员工具成为一个吸引人的利用目标，尤其是考虑到攻击者可以使用我们的机器来进一步传播攻击（例如，通过存储在开发人员机器上的身份验证令牌，甚至通过开发人员编写的软件）。
成为一名开发人员是值得的，但这也是一项有风险的业务。要为一个项目做出贡献，您本质上需要信任其作者，因为运行 npm install 或 make、构建 Java 或 C# 项目、自动化测试或调试等活动都意味着项目中的代码正在您的计算机上执行。
我们使用 工作区信任 功能的目标是找到正确的平衡，以防范少数想要破坏所有人利益的“坏苹果”，同时继续确保我们可以拥有使开发如此有趣的所有美好事物。
嘿，它只是一个编辑器，对吧？
是的，VS Code 是一个编辑器。但是，像大多数现代编辑器一样，它能够代表您运行工作区中的代码，以提供更丰富的开发体验。
运行和调试代码是一个明显的例子。可能不太明显的代码执行可能是 preLaunchTask，它在启动应用程序之前运行，并且可以运行一个具有执行与构建无关的任意代码的额外任务的构建。那么窃取您的加密钱包私钥的 npm 模块呢？进行简单的编辑，然后从 node_modules 文件夹加载恶意检查器，而不是全局安装的检查器。即使读取代码也可能具有欺骗性，攻击者可以使用 Unicode 黑客 在明处隐藏恶意代码。嘿，您甚至不必打开任何源代码 即可被控制。
这里的意图不是要吓跑您，让您远离所有优秀的工具（包括 VS Code）或让您改变职业。而是要提高人们的意识，当您从互联网上下载由您没有任何信任关系的人或组织编写的代码时，存在许多攻击机会。
打地鼠
在上述所有场景中，工具都按照它们的设计工作，并且在非恶意的代码库中，它们非常高效。设置 preLaunchTask 以在调试之前构建应用程序是一个很好的省时方法，因为您不必在每次更改后都从终端手动构建它。代码检查器是高度可定制的，以支持每个团队的首选编码准则和风格（是的，制表符与空格）。预提交钩子可以让您检查是否遗忘了某些内容，或者确保在提交之前运行测试。
现在，您不太可能同时遭受所有这些攻击。事实上，还没有（尚未）通过 VS Code 进行的攻击，因为有一个伟大的专家社区，他们在我们发现新的机会时会提醒我们。在我们引入工作区信任之前，我们的方法是在漏洞出现时，通过本地化的权限提示来解决每个场景。
例如，Jupyter 扩展警告用户，当您在笔记本中打开可视化工具时，嵌入式 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 上，我将从 Microsoft 组织在 GitHub 上提取的所有源代码都放入我的 ~/src 文件夹中。我将 ~/src 指定为受信任的文件夹，其下的所有内容都默认被信任。当我打开 ~/src/vscode 或 ~src/vscode-docker 等时，它们会被完全信任地打开，因为我信任我的组织编写和使用的代码。
我有一个单独的名为 ~/scratch 的文件夹（“scratchpad” 的缩写，您可以随意命名），我将所有其他内容都放在那里，并默认认为它是不可信的。然后，我根据每个文件夹做出信任决定。
为了使我的工作流程更顺畅，我将 "security.workspace.trust.startupPrompt" 设置为 "never"。
使用此设置，我不会收到模式对话框的提示，并且工作区会直接以受限模式打开。我已经决定 ~src/scratch 文件夹是不可信的，因此无需每次打开子文件夹时都提示我。如果我决定信任我正在读取或编写的代码，我可以单击两次快速启用该文件夹（VS Code 顶部的受限模式通知，然后是信任按钮）。
在我的 Windows 机器上，情况稍微有趣一些。我通常在使用 WSL 扩展的 Linux 的 Windows 子系统 (WSL) 上运行 Ubuntu 映像。我信任 Linux 上的 ~/src 文件夹，并且信任 Windows 端的 d:\src 文件夹。
团队中的一些人更进一步，关闭了顶部受限模式横幅（"security.workspace.trust.banner": "never"），只留下状态栏通知。对我来说，这有点过分了，顶部的横幅提醒我保持警惕，并在我从互联网上获取内容时帮助我保持警惕。
开源是了不起的
我们知道 VS Code 是您用来完成“真正”工作的工具，我们引入的任何障碍或阻碍只会减慢您构建和启动下一个独角兽的速度。你们中的许多人花时间通过 Twitter、Reddit 和问题联系我们，我们感谢您坦诚的反馈。我们根据您的意见在 1.58 版本中进行了许多 修复和改进，并期待继续对话。
展望未来，我们希望帮助 扩展作者 避免任意代码执行，并在受限模式下运行提供更多功能。我们的 路线图 指出了我们正在与 Visual Studio Marketplace 团队合作，为扩展生态系统带来额外安全性的工作（我们称之为“受信任的扩展”），包括验证的发布者、签名和特定于平台的扩展。简而言之，您可以将工作区信任视为帮助好的扩展做出良好决策。受信任的扩展将帮助您免受不良扩展的侵害。
在开放环境中构建 VS Code 的好处之一是社区可以帮助我们创造最佳体验。因此，请告诉我们如何改进流程，帮助您在尽可能不引人注意的同时保持安全。在现有问题上评论（礼貌地！）、提交新问题或在 Twitter 上发推文 @code，我们正在听！
谢谢，
Chris 和 VS Code 团队
祝您编码愉快（安全）！