General Discussion on Workspace Trust Feature

[Tyriar]

Trusted Workspace

The trusted workspaces concept is intended to centralize and unify a security conscious decision required by a variety of VS Code features. The easiest existing example to understand of this decision is with the ESLint extension. The ESLint extension will try to use the eslint module in the current folder that is opened in VS Code and execute code from it. Since you may have checked out a random repository from the web, this could be dangerous if the repository contains a corrupt eslint module. Notice that ESLint is not trying to be malicious, but rather, the repository/corrupt module is taking advantage of this automatic code execution.

With Trusted Workspaces, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Current Subscribers

Extensions

Extensions should use this guide to participate in workspace trust.

Tasks

Tasks will not execute in an untrusted workspace.

Status Bar Indication

A trusted state is indicated with a small green icon. An untrusted state is indicated with the icon and text.

Management

The following json editor is a stand-in for a more feature-rich editor. We intend to replace this soon.

Try it out

Enable the setting

Add "security.workspace.trust.enabled": true to your settings.json.

[sbatten]

The rich editor was introduced last milestone to replace the JSON editor. Here is a screenshot of the 1st draft which will get some love soon.

[hyangah]

Thanks for working on this feature. This will help extensions address the security issues around untrusted repositories in a more consistent and reliable way. A couple of questions:

1. It looks like the workspace trust setting is based on the folders. How will it work in multi-root workspaces? Should all the folders be trusted?

2. When a new folder (not yet trusted) is added to the already trusted workspace (by other extension or by a command), should the extension get deactivated or require trust again?

3. In case of our extension, the main concern is in the settings defined in the untrusted workspace/folder. So I ended up wrapping the WorkspaceConfiguration to filter out workspace/folder settings until users explicitly opt in (similar to typescript.tsdk).
   Benefit of this approach is that users can still use features from our extension without fully trust the workspace.
   Even basic features like code navigation or symbol search in Go extension need a tool execution using settings. So I think it's better to offer those features if we can run the tool using user settings safely rather than completely stopping the features.
   Ignoring values from workspace/folder(+language) settings using the WorkspaceConfiguration inspect api isn't impossible but still tedious. Since the trusted workspace concept is officially supported, can you offer a variation of WorkspaceConfiguration.get that ignores settings from untrusted workspace?

[carlocardella]

@hwsamuel, disable security.workspace.trust.enabled

[anomaly256]

It is definately showing me this prompt every time vs code starts and I open a given workspace if I elect not to trust the workspace in question the previous time. ...and in one case it showed it to me multiple times within the same workspace during the same vs code executation instance when I was navigating around subdirectories within the project. Ultimately I do trust the workspace in question, but imo I don't think I should have to - to my knowledge I don't have anything that should be executing arbitrary files inside the project when I launch vs code? And if I do, I wish for that to never happen. This behaviour, automatically executing arbitrary code within the workspace directory on editor start, should be opt-in not opt-out if I disable the prompt, right?

edit: Just now I tried setting security.workspace.trust.startupPrompt to 'never' and vs code immediately prompted me to trust the open workspace again. I get what you're trying to do here but this needs to be reworked a bit I think before pushing it onto everyone

[anomaly256]

Also.. just wanted to share my 'lol' at the setting item 'Trust: Empty Window - Controls whether or not the empty window is trusted by default within VS Code' what even is this?

[lszomoru]

edit: Just now I tried setting security.workspace.trust.startupPrompt to 'never' and vs code immediately prompted me to trust the open workspace again. I get what you're trying to do here but this needs to be reworked a bit I think before pushing it onto everyone

This should not be the case.
Do you mind sharing the exact steps that you have performed so that I can create an issue tracking this?

[sybrew]

"security.workspace.trust.startupPrompt": "never"

^ that doesn't work. For example, I open the file via Filezilla, and I still get the pop-up. I expect execution to be disabled without any prompt.

[lszomoru]

@sybrew, the "security.workspace.trust.startupPrompt" setting controls the workspace trust prompt when opening an untrusted folder the very first time. I believe that the prompt that you are seeing is related to opening an untrusted file in a trusted environment, but to be certain do you mind sharing the exact steps that you follow when seeing the prompt. Thank you!

[bhubr]

Hello,

While the motivation for this is very well explained above, and it can certainly protect less experienced users, I suggest that one of these two options be considered:

• Ask users to explicitly opt-in for this feature, explaining why it's a good idea.
• Make it really easier to opt-out.

From a user's point of view, there's nothing worse than your trusted software behaving differently than before, with no explanation, especially when it just keeps bugging you (Y'see, I tend to trust my own workspaces 😊).

[busticated]

@lszomoru

with the following in my project's settings.json file:

    "security.workspace.trust.startupPrompt": "never",
    "security.workspace.trust.enabled": false,

...i'm still seeing a prompt with "Do you trust the authors of the files in this folder".

this is preventing my end-to-end tests from running to completion. is there a way to entirely disable this feature in this context?

edit: ah, i see there'a flag i can pass in --disable-workspace-trust (docs)

apologies for the noise 🙏

[ehsanpaknejad]

edit: Just now I tried setting security.workspace.trust.startupPrompt to 'never' and vs code immediately prompted me to trust the open workspace again. I get what you're trying to do here but this needs to be reworked a bit I think before pushing it onto everyone

This should not be the case. Do you mind sharing the exact steps that you have performed so that I can create an issue tracking this?

I think all we want is to stop coming this blue message

and "security.workspace.trust.startupPrompt to never" does not stop this. what can? The answer is:
"security.workspace.trust.banner": "never"

this option is not shown in (Preferences -> Setting) by default

First you should set it in "setting.json" file. The location:
Windows: APPDATA\Code\User\settings.json
macOS: HOME/Library/Application Support/Code/User/settings.json
Linux: HOME/.config/Code/User/settings.json

then add this line:
"security.workspace.trust.banner": "never",
Please be careful about semicolon of previous line. like the image (last line & semicolon of end of above line)

ONE THING MORE. If it didn't work or the line you wrote was greyed color like this image, Update you VS Code. My old VS Code (version 1.57) did not had the setting and this line start to work after update to version 1.62.

Please be aware: now the VS Code doesn't show the Blue message and still open all new files as "untrusted".

[humphd]

One use case that I have as a prof is to download and grade student submissions. I do this thousands of times per semester, and I really wish I had a checkbox to Not trust a parent folder once vs. only being able to blanket Trust the parent:

For me, I'd be find to not trust ~/Downloads, set that once, and never have to do this dance again.

Could that checkbox be altered to affect the parent for either the Yes or No case?

[trevor-makes]

Why aren't VSCode extensions running in a sandbox? A "just trust me" dialog seems like an anti-security feature to me.

I found this issue discussing this very thing, but it doesn't seem to have gotten any traction: #52116

@isidorn I see you assigned that issue to yourself. What do you think?

[teohhanhui]

There needs to be a way to trust "just once" for the current open editor. I don't want to have to maintain a list of trusted folders.

[gardner]

This is a very noisy feature. Throwing up a modal every time a new folder is opened is annoying. Please use a sane default. One idea is to open everything untrusted and then have the user trust a folder if they want the addition features.

[Coresi7]

This feature is a piece of SxxT, could vscode just to be a quite, swift and silenced TEXT EDITOR or IDE only? This feature will prevent non-programmers to use vscode, they will ask for notepad++ or something else instead, even a computer HAS installed a vscode, because they do not understand what they should do to this dialog. Trust or untrust, why should I care?

As an IDE, no such kind of IDE such as visual studio or jetbrains has such fXXking idiot feature to annoying users, but they definitely do more than a vscode do, is that it?

Just do what vscode should do, leave other things to expertise softwares (such as anti-virus softwares), please!

[Tyriar]

Please use a sane default. One idea is to open everything untrusted and then have the user trust a folder if they want the addition features.

Many features get disabled with this, for example language support. If we did this without prompting, many users would not discover language support for Python for example and assume it's broken.

Trust or untrust, why should I care?

As an IDE, no such kind of IDE such as visual studio or jetbrains has such fXXking idiot feature to annoying users, but they definitely do more than a vscode do, is that it?

Just do what vscode should do, leave other things to expertise softwares (such as anti-virus softwares), please!

@Coresi7 the reason this feature exists it because we received several security vulnerability reports, both for core and for extensions. And what was starting to happen was core and extensions were all implementing their own system to cover this. This feature consolidates it so there is a single prompt and that's it. If it's annoying you can essentially disable it by checking this box:

For finer grained control, run the manage workspace trust command and add your C or / drive or whatever.

I agree it's unfortunate that we need this at all, but we (vscode core and 1st party extensions) have a hard requirement to not cause a potential remote code execution vulnerability upon the opening of a folder. It's pretty obvious why we need to do this.

---

@sbatten @lszomoru is there anything else to do on this issue? Are we for example considering a checkbox to just trust everything to help the class of users that don't care, or is that too heavy handed?

[Coresi7]

Yes, maybe devs and IT techs could understand this (but not all of devs or it guys), but users do not. They will complain vscode is hard to use, because they do not understand why. They even do not know how to install a plugin, or use settings, they care how fast it can be or how to make the fonts or words rendered correct and meaningful without install heavy text editor tool (such as an IDE, or office like document editor). For this part of users, they do never care about trust or not.
We can mark everything as untrusted by default, if users need to use a plugin or extension feature, give a hint that features are disabled, trust this workspace to enable them, should be better.

[Tyriar]

@Coresi7 that's why we link off to extensive docs. It's a complicated problem that needs to balance usability and discoverability and this is what we came up with after months of discussion. One of the main reasons it's not as you're suggesting is because VS Code isn't really that useful without workspace trust since so many things are turned off, so we ask immediately upon folder open. It actually is already kind of is as you ask actually as several features request workspace trust immediately upon folder open (tasks, git, terminal, python language smarts).

Again it's unfortunate it needs to exist, but it's there to protect users.

[sbatten]

There are likely other feature requests that I did not account for, but reading through the recent discussion and cross-referencing with out feature requests, I am closing this item in favor of the individual issues per problem.

[TamaMcGlinn]

@Tyriar what did you mean by this?

For finer grained control, run the manage workspace trust command and add your C or / drive or whatever.

Is there a command like vscode --trust-workspace "~" that would trust that workspace without the prompt inside vscode?

[Tyriar]

@TamaMcGlinn open the command palette (f1 or cmd/ctrl+shift+p) and select manage workspace trust:

You can then add whatever directory you want to permanently trust to the list in the bottom. For example I trust C:\GitHub where I clone everything I trust, and C:\Playground where I don't necessarily: