工作区信任
2021 年 7 月 6 日，作者：Chris Dias，@chrisdias
我能信任自己吗？这是许多 Visual Studio Code 用户在1.57 更新 之后面临的存在主义问题。
虽然我们无法为您解答这个问题，但我们可以向您详细说明我们引入工作区信任概念的原因。
但首先，一点背景知识。
猫和键盘，还有坏苹果
互联网上充满了快乐的事情，比如猫在键盘上打字的视频。
对于开发者来说，互联网上也充满了工具、软件包和开源项目，它们由好人创建，他们希望帮助您解决您已经工作了几个小时的问题。像 VS Code 这样的开发工具集成了包管理器、代码 linter、任务运行器、捆绑器等，以提供愉快的体验，利用来自不断发展的社区的最新和最强大的进展。
但是，这种丰富的生态系统带来的生产力通常是由于我们为开发机器提供的广泛访问权限造成的。再加上快速的发展和病毒式传播，开发工具成为了攻击者的目标，尤其是在攻击者可以使用我们的机器进一步传播攻击的情况下（例如，通过存储在开发机器上的身份验证令牌，甚至通过开发人员编写的软件）。
成为一名开发者很有回报，但也存在风险。为了贡献一个项目，您本质上需要信任其作者，因为像运行npm install 或make，构建 Java 或 C# 项目，自动测试或调试等活动，都意味着来自项目的代码正在您的计算机上执行。
我们通过工作区信任 功能的目标是找到平衡，以确保安全，防止那些少数几个想要破坏它的人，同时继续确保我们能够拥有所有让开发变得如此有趣的美好事物。
嘿，这只是一个编辑器，对吧？
是的，VS Code 是一款编辑器。但是，与大多数现代编辑器一样，它能够代表您运行来自工作区中的代码，以提供更丰富的开发体验。
运行和调试代码是一个明显的例子。可能不那么明显的代码执行可能是preLaunchTask，它在启动应用程序之前运行，并且可以运行构建，该构建包含执行与构建无关的任意代码的额外任务。那么 npm 模块会窃取您的加密钱包私钥呢？进行简单的编辑，就会加载来自node_modules 文件夹的恶意 linter，而不是全局安装的 linter。即使阅读代码也可能是具有欺骗性的，攻击者可以使用 Unicode 技巧在显眼处隐藏恶意代码。哎呀，您甚至不需要打开任何源代码就可以被攻击.
这里的目的不是让您远离所有伟大的工具（包括 VS Code），也不是让您改变职业。而是要提高您对从互联网上下载代码时存在的攻击机会的认识，这些代码是由您没有建立任何信任关系的个人或组织编写的。
打地鼠
在上面所有场景中，工具都在按设计运行，在非恶意代码库中，它们非常高效。设置preLaunchTask 以在调试之前构建应用程序是一个很大的省时方法，因为您不必在每次更改后从终端手动构建它。linter 是高度可定制的，以支持每个团队的首选编码指南和样式（是的，制表符与空格）。预提交钩子可以让您检查是否遗漏了什么，或者确保在提交之前运行测试。
现在，您不太可能同时遭受所有这些攻击。事实上，还没有（尚未）通过 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 上，我把从 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 和 Issue 上与我们联系，感谢你们的坦诚反馈。我们根据你们的意见在 1.58 版本中做了一系列 修复和改进，并期待继续与你们交流。
展望未来，我们希望帮助 扩展作者 避免任意代码执行，并在限制模式下提供更多功能。我们的 路线图 指明了我们正在与 Visual Studio Marketplace 团队合作进行的工作，以增强扩展生态系统的安全性（我们称之为 "Trusted Extensions"），包括经过验证的发布者、签名和平台特定的扩展。简而言之，你可以将工作区信任视为帮助好的扩展做出好的决定。Trusted Extensions 将帮助你抵御不良扩展。
在开源环境下构建 VS Code 的好处之一是，社区可以帮助我们创造最佳的用户体验。因此，请告诉我们如何才能改善工作流程，在确保安全的同时，尽可能地减少干扰。在 现有 Issue 中发表评论（礼貌地！），提交新的 Issue，或者在 Twitter 上给我们发消息 @code，我们一直在聆听！
感谢您，
Chris 和 VS Code 团队
祝您编码愉快（安全地！）！