工作區信任
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 以在偵錯之前建置應用程式是一個很棒的省時工具，因為您不必在每次變更後都從終端機手動建置它。程式碼檢查器具有高度可自訂性，可以支援每個團隊偏好的程式碼撰寫指南和風格（是的，縮排要用 Tab 還是空格）。預先提交 Hook 可讓您檢查是否遺忘了一些內容，或確保在提交之前執行測試。
現在，您不太可能同時遭受所有這些攻擊。事實上，還沒有（尚未）發生透過 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 上，我將我從 Microsoft 組織在 GitHub 上提取的所有來源程式碼都放在我的 ~/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 和 Issues 上與我們聯繫，我們感謝您的坦誠回饋。我們根據您的意見，在 1.58 版本中進行了許多修正和改進，並期待繼續進行對話。
展望未來，我們希望協助擴充功能作者避免任意程式碼執行，並在受限模式下執行時提供更多功能。我們的Roadmap 指出了我們正在與 Visual Studio Marketplace 團隊合作，為擴充功能生態系統帶來額外安全性（我們稱之為「受信任的擴充功能」），包括經過驗證的發行商、簽署和平台特定的擴充功能。簡而言之，您可以將工作區信任視為協助良好的擴充功能做出良好的決策。受信任的擴充功能將協助您防範不良的擴充功能。
在開放環境中建置 VS Code 的好處之一是，社群可以協助我們創造最佳的體驗。因此，請告訴我們如何改進流程，協助您在保持安全性的同時盡可能不引人注目。對現有問題發表評論（禮貌地！）、提交新問題，或在 Twitter 上 @code 推文給我們，我們正在傾聽！
謝謝，
Chris 和 VS Code 團隊
快樂編碼（安全地）！