工作區信任
2021 年 7 月 6 日，作者：Chris Dias，@chrisdias
我能相信自己嗎？自 1.57 版本更新以來，這是許多 Visual Studio Code 使用者面臨的終極問題。
雖然我們無法替您回答這個問題，但我們可以告訴您更多關於我們為何引入“工作區信任”概念的原因。
但首先，我們需要一些背景知識。
貓和鍵盤，以及害群之馬
網際網路上充滿了快樂的事情，比如貓咪在鍵盤上打字的影片。
對於開發者而言，它也充滿了由好人構建的工具、包和開源專案，他們希望幫助您解決您已花費數小時處理的問題。像 VS Code 這樣的開發工具集成了包管理器、程式碼 Linter、任務執行器、打包器等，以利用不斷發展的社群中的最新和最偉大的進步，提供愉快的體驗。
然而，這種豐富的生態系統所帶來的生產力，往往是我們為開發機器提供廣泛訪問許可權的結果。再結合快速迭代、病毒式傳播和消費的特性，開發工具成為了一個吸引人的攻擊目標，尤其是考慮到攻擊者可以使用我們的機器來進一步傳播攻擊（例如，透過儲存在開發者機器上的身份驗證令牌，甚至透過開發者編寫的軟體）。
成為一名開發者是很有價值的，但它也是一項有風險的工作。要為一個專案做出貢獻，您固有地需要信任它的作者，因為執行 npm install 或 make、構建 Java 或 C# 專案、自動化測試或除錯等活動，都意味著來自專案的程式碼正在您的計算機上執行。
我們引入 工作區信任 功能的目標是找到正確的平衡點，既要保護我們免受少數“害群之馬”的侵害，又要確保我們能繼續擁有所有讓開發變得如此有趣的便利之處。
嘿，它只是一個編輯器，對嗎？
是的，VS Code 是一個編輯器。然而，像大多數現代編輯器一樣，它能夠代表您執行工作區中的程式碼，以提供更豐富的開發體驗。
執行和除錯程式碼是一個顯而易見的例子。不那麼明顯的程式碼執行可能是 preLaunchTask，它在啟動應用程式之前執行，並且可以執行一個構建，該構建包含一個執行與構建無關的任意程式碼的額外任務。那麼竊取您的加密錢包私鑰的 npm 模組呢？進行簡單的編輯，惡意 Linter 就會從 node_modules 資料夾載入，而不是全域性安裝的那個。即使是閱讀程式碼也可能具有欺騙性，攻擊者可以使用 Unicode 技巧來隱藏惡意程式碼於明處。見鬼，您甚至不需要開啟任何原始碼就能被攻陷。
這裡的目的不是為了嚇跑您，讓您遠離所有這些出色的工具（包括 VS Code）或讓您改行。而是為了提高意識，當您從您沒有信任關係的個人或組織那裡下載網際網路上的程式碼時，存在許多攻擊機會。
打地鼠遊戲
在所有上述場景中，這些工具都是按其設計工作的，在非惡意的程式碼庫中，它們極具生產力。設定 preLaunchTask 在除錯前構建應用程式可以節省大量時間，因為您不必在每次更改後都手動從終端構建它。Linter 高度可定製，以支援每個團隊首選的編碼指南和樣式（是的，製表符 vs. 空格）。預提交掛鉤允許您檢查是否遺漏了某些內容，或者確保在提交之前執行測試。
現在，您不太可能同時遭受所有這些攻擊。事實上，目前（還）沒有透過 VS Code 發生的攻擊，因為有一個由專家組成的優秀社群，他們在新機會出現時及時告知了我們。在引入工作區信任之前，我們的方法是在每個漏洞點透過本地化的許可權提示來解決每個場景。
例如，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（“草稿本”的縮寫，您顯然可以隨意命名），我把所有其他東西都放在裡面，並預設假設它是不受信任的。然後，我逐個資料夾做出信任決定。
為了使我的工作流程順暢，我將 "security.workspace.trust.startupPrompt" 設定設定為 "never"。
有了這個設定，我就不會收到模式對話方塊的提示，工作區會直接在受限模式下開啟。我已經決定 ~src/scratch 資料夾不受信任，所以沒有必要每次開啟子資料夾時都提示我。如果我決定我確實信任我正在閱讀或編寫的程式碼，我可以透過兩次快速點選在資料夾上啟用它（VS Code 頂部的受限模式通知，然後是信任按鈕）。
在我的 Windows 機器上，情況更有趣一些。我通常使用 WSL 擴充套件程式在 Windows Subsystem for Linux (WSL) 上執行的 Ubuntu 映象中工作。我信任 Linux 上的 ~/src 資料夾，並且我信任 Windows 端的 d:\src 資料夾。
團隊中的一些人更進一步，關閉了頂部的受限模式橫幅（"security.workspace.trust.banner": "never"），只留下狀態列通知。對我來說，這有點過了，頂部的橫幅讓我保持警惕，並提醒我在從網際網路上拉取內容時要保持警惕。
開源非常棒
我們知道 VS Code 是您用來完成“真正”工作的工具，我們引入的任何障礙或阻礙只會減慢您構建和推出下一個獨角獸的速度。許多人花時間在 Twitter、Reddit 和 issue 中聯絡我們，我們感謝您的坦誠反饋。我們根據您的意見在 1.58 版本中進行了許多修復和改進，並期待繼續對話。
展望未來，我們希望幫助擴充套件作者避免任意程式碼執行，並在受限模式下提供更多功能。我們的路線圖記錄了我們正在與 Visual Studio Marketplace 團隊合作進行的工作，目的是為擴充套件生態系統帶來額外的安全性（我們稱之為“受信任的擴充套件”），包括經過驗證的釋出者、簽名和特定於平臺的擴充套件。簡而言之，您可以將工作區信任視為幫助好的擴充套件做出良好決策。受信任的擴充套件將幫助您免受壞擴充套件的侵害。
開放構建 VS Code 的好處之一是社群可以幫助我們創造最佳體驗。因此，請告訴我們如何改進流程，幫助您保持安全，同時儘可能不引人注目。請（禮貌地！）在現有 issue上發表評論，提交新 issue，或在 Twitter 上@我們@code，我們正在傾聽！
謝謝，
Chris 和 VS Code 團隊
快樂編碼（安全地）！