Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support VS Code Workspace Trust feature #1051

Closed
dummdidumm opened this issue Jun 12, 2021 · 4 comments
Closed

Support VS Code Workspace Trust feature #1051

dummdidumm opened this issue Jun 12, 2021 · 4 comments
Labels
feature request New feature or request Fixed Fixed in master branch. Pending production release.

Comments

@dummdidumm
Copy link
Member

dummdidumm commented Jun 12, 2021

The new VS Code version introduced "Workspace Trust". If someone doesn't trust a folder/workspace they have opened, VS Code only provides limited interaction with the code base. This includes extensions: They are turned off completely, if they don't implement some of the Workspace Trust APIs. Extension can provide a description of what subset of functionality should be enabled. More on that and a questionnaire which helps determining what to do here: microsoft/vscode#120251

I think what we need to do in Workspace Trust is:

  • Disable loading the svelte.config.js, it could contain malicious code. If one is present, we should turn off running the diagnostics of the Svelte compiler as we can't know for sure how to preprocess the files.
  • Don't load the user's version of prettier/svelte/svelte-preprocess (importPackage.ts) and instead use our own version of that
  • check the built-in typescript extension of VS Code to see if they turn off something, and turn that off, too . Edit: They turn of these settings which don't affect us
  • investigate if we can reenable the ls-path and node executable setting to be workspace settings. If the user trusts the workspace, he likely also trusts the workspace settings
@dummdidumm dummdidumm added the feature request New feature or request label Jun 12, 2021
dummdidumm referenced this issue Jun 16, 2021
Due to security reasons: If this could be set in the workspace, a malicious workspace could point this to an arbitrary executable.
dummdidumm pushed a commit to dummdidumm/language-tools that referenced this issue Jul 6, 2021
dummdidumm added a commit that referenced this issue Jul 8, 2021
#1051

Not removing the the ls server path scope for now to ensure backwards compatibility. Lift that restriction and bump the minimum required VS Code version later.
@dummdidumm
Copy link
Member Author

Support added in #1086 .
Not removing the the ls server path scope for now to ensure backwards compatibility. Lift that restriction and bump the minimum required VS Code version later.

@stephtr
Copy link

stephtr commented Dec 18, 2021

When are you planning to lift that restriction?

@acls
Copy link

acls commented Feb 16, 2023

@dummdidumm Would it be possible to remove the "scope": "application" restriction now?

dummdidumm added a commit that referenced this issue Jul 10, 2023
#1051
#678
This was the missing feature in #1086, but now that we have a new minimum required VS Code version which includes workspace trust, we can lift the restriction and allow the security-sensitive settings when the workspace is trusted.
dummdidumm added a commit that referenced this issue Jul 11, 2023
…2089)

#1051
#678
This was the missing feature in #1086, but now that we have a new minimum required VS Code version which includes workspace trust, we can lift the restriction and allow the security-sensitive settings when the workspace is trusted.
@dummdidumm dummdidumm added the Fixed Fixed in master branch. Pending production release. label Jul 11, 2023
@dummdidumm
Copy link
Member Author

"scope": "application" is lifted now in favor of workspace trust

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request Fixed Fixed in master branch. Pending production release.
Projects
None yet
Development

No branches or pull requests

3 participants