-
-
Notifications
You must be signed in to change notification settings - Fork 203
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
Labels
Comments
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.
Support added in #1086 . |
When are you planning to lift that restriction? |
@dummdidumm Would it be possible to remove the |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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:
importPackage.ts
) and instead use our own version of thatThe text was updated successfully, but these errors were encountered: