工作空间信托
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，而不是全局安装的 linter。即使阅读代码可能具有欺骗性，攻击者也可以使用 Unicode 黑客技术将恶意代码隐藏在众目睽睽之下。哎呀，您甚至不必打开任何源代码就可以拥有。
这里的目的并不是让您远离所有优秀的工具（包括 VS Code）或让您改变职业。这是为了提高人们的认识，当您从互联网下载由与您没有任何类型的信任关系的个人或组织编写的代码时，存在许多攻击机会。
打地鼠
在上述所有场景中，这些工具都按照设计的方式工作，并且在非恶意代码库中，它们非常高效。在调试之前设置preLaunchTask来构建应用程序可以节省大量时间，因为您不必在每次更改后从终端手动构建它。Linter 是高度可定制的，以支持每个团队首选的编码指南和风格（是的，制表符与空格）。预提交挂钩可让您检查是否忘记了某些内容或确保测试在提交之前运行。
现在，您不太可能同时遭受所有这些攻击。事实上，还没有通过 VS Code 进行利用，因为有一个伟大的专家社区让我们意识到新机会的出现。在 Workspace Trust 之前，我们的方法是使用本地化的权限提示来解决漏洞点的每种情况。
例如，Jupyter 扩展警告用户，当您在笔记本中打开可视化工具时，嵌入式 JavaScript 可以运行：
ESLint 漏洞非常棘手，因为它在工作区加载时运行（这是我们的第一个模式对话框）。
事实证明，这是一场失败的战斗。用户会被多个（且略有不同）权限提示打断，这些提示不适用于整个工作区。我相信你，你，你，你，不是你，还有你，但只在星期二。对我们来说，这是一场持续不断的打地鼠游戏，在每个漏洞暴露时都用另一个提示来堵住它。
因此，我们在构建 VS Code 时遵循的模式之一是查看工具和扩展中正在实现类似但不一致的体验，并看看我们是否可以将其纳入核心。信任提示遵循这种模式，因此我们决定考虑构建一种工具和扩展都可以利用的体验和 API，并提供（希望）更清晰的用户体验。
相信
现在您已经了解了在您不知情的情况下运行代码的一些不同方式，希望您能更好地了解我们为什么要预先提出这个问题。
我们特别询问您是否信任此工作区的作者，因为 VS Code 无法判断代码是否是恶意的（嘿，我们只知道 1 和 0），它来自哪里，如果您打算为该项目做出贡献， ETC。
另一方面，你很聪明，你知道代码来自哪里：你（好吧），你的公司（可能好吧），你的好友 Kai（取决于），或者互联网上的某个随机人（绝对不是）。
这些知识有助于使工具变得更加智能。如果您信任作者，那就太好了！这些工具和扩展程序已获准执行其任务并提供神奇的体验，我们不会再打扰您了。
如果你不这样做，你就是在告诉我们小心 VS Code，不要执行任何代码。这就是我们所说的限制模式，其中潜在有害的功能被禁用，以便您可以更安全地浏览代码并最终做出明智的决定。
但是那个对话框！
我们听到您的声音，模式对话框非常大，并且它会在您打开的每个新文件夹中不断出现，除非您采取措施对其进行配置。
我们并不是从这个设计开始的。我们研究了ESLint 模态对话框传奇，并问自己是否可以使用视觉线索和尽可能长时间延迟的单个通知提示来提供非阻塞体验。我们希望不引人注目，以限制模式开始（在您没有真正注意到的情况下），并在最后一刻提示信任。
我们引入了“被动”信任通知，您可以在其中告诉我们您是否信任该工作区。我们循环进行了各种 UI 处理，以表明工作区不受信任，包括增强“设置”齿轮图标并引入新的安全图标。
如果您使用Insiders版本，您将获得 VS Code 中新体验的最新迭代，就像我们正在讨论的 Workspace Trust 一样。Insider 每天都会发布，我们用它来构建 VS Code。
作为用户（您！）的想法可以根据您的条件决定何时授予或拒绝对工作区的信任。当工具或扩展确实需要访问权限时，我们才会发出通知，询问您是否信任工作区：
现在，我相信你们中的许多人都会同意，VS Code 遭受了我们所说的“通知疲劳”的困扰（我保证我们正在努力解决这个问题？？？）。在我们的测试中，我们发现人们只是忽略了该通知。用户没有看到设备上的通知，甚至没有看到新的安全图标。使用数据显示，通过被动通知授予信任的比率非常低。在用户研究中，我们看到人们花所有的时间认为他们已经破坏了某些东西，然后花时间排除故障，试图恢复到他们的预期状态。
我们打算尽可能不引人注目并延迟，但现实是，在限制模式下，产品感觉很糟糕，人们认为这是他们的错。对我们俩来说都不是一个好地方。
让您掌控一切
信任文件夹的决定对 VS Code 的功能具有根本性影响，因此经过所有研究，我们认为正确的做法是在尝试打开文件夹时立即询问信任问题。由于模式对话框具有破坏性，因此我们尝试通过使对话框功能强大来平衡问题，以便您可以回答几个问题，最终在日常工作中更少地看到提示。
根据我们自己的测试以及对其他开发人员的采访，我们发现人们通常有一个主文件夹，他们在其中放置所有源代码并认为它值得信赖。因此，我们添加了直接从对话框信任父文件夹的功能。您可以一键信任它和所有子文件夹，然后您将不会再看到信任提示。
工作空间信任编辑器
Workspace Trust 编辑器为您提供了对信任内容的额外控制，并将在 1.58 版本中进行更新，以便更轻松地配置该功能以满足您的需求。
而且因为您可以自定义行为，所以有很多方法可以访问信任编辑器？？？。单击受限模式状态栏消息、受限模式横幅中的管理链接、齿轮菜单，或打开命令面板 ( F1 ) 并使用工作区：管理工作区信任命令。
在工作区信任编辑器中，您可以信任当前文件夹、父文件夹（和所有子文件夹）以及计算机上的任何文件夹。
您还可以快速跳转到所有工作区信任设置以微调体验。
我们如何使用 Workspace Trust
没有人喜欢用牙线清洁牙齿，但我们还是这么做，因为我们知道这是正确的做法。没有人愿意考虑安全问题，但我们也知道这是正确的做法。通过定制体验，您可以保持愉快的开发体验，同时保护自己免受开发固有的威胁（有趣的牙线？！？）。
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 扩展。我信任~/srcLinux 上的文件夹，也信任d:\srcWindows 端的文件夹。
团队中的一些人更进一步，关闭了顶部的受限模式横幅 ( "security.workspace.trust.banner": "never")，只留下状态栏通知。对我来说这太过分了，顶部的横幅让我保持诚实，并帮助提醒我在从互联网上退出时保持警惕。
开源很棒
我们知道 VS Code 是您用来完成“真正”工作的工具，我们引入的任何减速带或障碍只会减慢您构建和启动下一个独角兽的速度。你们中的许多人花时间在 Twitter、Reddit 和问题上进行交流，我们感谢你们的坦诚反馈。我们根据您的意见在 1.58 版本中进行了许多修复和改进，并期待继续对话。
展望未来，我们希望帮助扩展作者避免任意代码执行，并在受限模式下运行时提供更多功能。我们的路线图指出了我们与 Visual Studio Marketplace 团队正在开展的工作，旨在为扩展生态系统（我们称之为“受信任的扩展”）带来额外的安全性，包括经过验证的发布者、签名和特定于平台的扩展。简而言之，您可以将 Workspace Trust 视为帮助好的扩展做出好的决策。Trusted Extensions 将帮助您免受不良扩展的侵害。
公开构建 VS Code 的好处之一是社区可以帮助我们创造尽可能最佳的体验。因此，请告诉我们如何改善流程，帮助确保您的安全，同时尽可能不引人注目。对现有问题发表评论（礼貌地！），提交新问题，或发推文给我们@code，我们正在倾听！
谢谢，
Chris 和 VS Code 团队
快乐编码（安全）！