Workspace Trust for Extension Authors

[sbatten]

This issue will be updated as information becomes available. Please subscribe and check back.

This issue will function as the landing page for extension authors while Workspace Trust is in development. If you are an extension author, please subscribe to this issue to receive notifications when the issue is updated.

Note that the feature has been in the works for some time now and we are nearing the phase where we would like extension authors to test it out and provide feedback. Once it is ready, we will post the extension authoring guide in this issue so that you can try adopting the new API.

To learn more about the development of the feature, check out our development issue: https://github.com/microsoft/vscode/issues/106488

[sbatten]

Workspace Trust Extension Guide

What is Workspace Trust?

Workspace Trust is a feature driven by the security risks associated with unintended code execution when a user opens a workspace in VS Code. For example, consider that a language extension, in order to provide functionality may execute code from the currently loaded workspace. In this scenario, the user should trust that the contents of the workspace are not malicious. Workspace Trust centralizes this decision within VS Code so that extension authors do not have to handle this themselves. VS Code will offer static declaration and API support to onboard extensions quickly without the need to duplicate code across extensions.

Onboarding

Static Declarations

In your extension's package.json, VS Code will support the following new property:

capabilities:
    untrustedWorkspaces:
        { supported: true } |
        { supported: false, description: string } |
        { supported: 'limited', description: string, restrictedConfigurations?: string[] }

For the supported property, the following values are accepted:

• true - The extension is fully supported in an untrusted workspace as it does not need workspace trust to perform any functionality. It will be enabled exactly as before.
• false - The extension is not supported in an untrusted worskpace as it cannot function without workspace trust. It will remain disabled until workspace trust is granted.
• 'limited' - Some features of the extension are supported in an untrusted workspace. Trust-sensitive features should be disabled until workspace trust is granted. The extension can use our API to hide or disable these features. Workspace settings can be gated by trust automatically using the restrictedConfigurations property.

For the description property, a description of why trust is needed must be provided to help the user understand what features will be disabled or what they should review before granting or denying workspace trust. If supported is set to true, this property is ignored.

💡The value for the description property should be added to package.nls.json and then referenced in the package.json file for localisation support.

For the restrictedConfigurations property, an array of configuration settings IDs are provided. When provided, the extension will not be given workspace-defined values for the given settings in an untrusted workspace.

How do I decide how my extension should support untrusted workspaces?

To help extension authors understand what is in scope for Workspace Trust, we have created a list of questions to consider.

Does my extension have a main entry point?

If the extension does not have a main entry point (ex: themes, language grammars), the extensions does not require workspace trust. Extension authors do not need to take any action for such extensions as they will continue to function independent whether the workspace is trusted or not.

Does my extension rely on files in the opened workspace to provide features?

This can mean things like settings that can be set by the workspace or actual code in the workspace. If the extension never uses any of the contents of the workspace, it probably doesn't require trust. Otherwise, take a look at the other questions.

Does my extension treat any contents of the workspace as code?

The most common example of this is using a project's workspace dependencies, such as the node modules stored in the local workspace. A malicious workspace might check in a compromised version of the module. Thus, this is a security risk for the user and extension. Auxiliary to this, an extension may rely on JavaScript or other configuration files that control the extension or other modules' behavior. However, many other examples could occur, such as executing an opened code file to determine its output a error reporting.

Does my extension use settings that can be defined in the workspace in any code execution?

Your extension might use settings values as flags to a CLI that your extension executes. If these settings are overridden by a malicious workspace, they could be used as an attack vector against your extension. On the other hand, if the settings' values are only used to detect certain conditions, (e.g. if the value of a preferred shell setting is bash or pwsh determines what documentation you show), then it may not be a security risk and does not require Workspace Trust. Below is a section dedicated to guidance on settings to help you find the optimal configuration for your extension.

This is not an exhaustive list of cases that might require Workspace Trust. As we review more extensions, we will update this list. Use this list to think of similar behavior your extension might be doing when considering Workspace Trust.

What if I don't make changes to my extension?

As mentioned above, an extension that does not contribute anything to their package.json will be treated as not supporting untrusted workspaces. It will be disabled when the workspace is not trusted and the user will be notified that some extensions are not working due to Workspace Trust. This measure is the most security-conscious approach for the user. Even though this is the default, it is still a best practice to set the appropriate value indicating that as an extension author, you have made the effort to protect the user and your extension from malicious workspace content.

How do I use the API?

As described above, the first step to using the API is adding the static declarations to your package.json. The easiest method of onboarding would be to use a false value for the supported property. Once again, this is the default behavior even if you do nothing, but it's a great signal to the user that you have made a deliberate choice. In this case, your extension does not need to do anything else. It will simply not be activated until trust is given and your extension can know that it is executing with the consent of the user. However, if your extension only requires trust for part of its functionality, this is likely not the best option.

For extensions that wish to gate their features on Workspace Trust, they should use the limited value for the supported property, and we provide the following API:

export namespace workspace {
    /**
        * When true, the user has explicitly trusted the contents of the workspace.
        */
    export const isTrusted: boolean;

    /**
        * Event that fires when the current workspace has been trusted.
        */
    export const onDidGrantWorkspaceTrust: Event<void>;
}

We provide a property to determine if the current workspace is trusted and an event for listening to when trust has been granted to the workspace. You can use these block specific code paths and perform any necessary registrations once the workspace has been trusted.

We also expose a context key isWorkspaceTrusted for use in when clauses as described below.

What about my contributions?

Commands, Views, or other UI

When the user has not trusted the workspace, they will operating in a mode with functionality geared towards browsing code. Any features that you provide that will not be trusted should be hidden from the user. This can be done via when clauses and the context key isWorkspaceTrusted. Since code can still call a command even if it is not presented in the UI, you should still block execution or not register a command based on the API above in your extension code.

Configurations/Settings

First, you should review your settings to determine if they need to take trust into account. As described above, a workspace may define a value for a setting that your extension consumes that is malicious to the use. If you identify settings that are vulnerable, you should use 'limited' for the supported property and list the setting ID in the restrictedConfigurations array.

When you add a setting ID to the restrictedConfigurations array, VS Code will only return the user-defined value of the setting in an untrusted workspace. This means your extension needs no additional code changes to handle the setting. When trust is granted, a configuration change event will fire in addition to the workspace trust event.

What is the guidance for debug extensions?

VS Code will prevent debugging in an untrusted workspace. For this reason, generally, debugging extensions do not need to additionally require trust and should select true for the supported property. However, if your extension provides additional functionality, commands, or settings that are not part of the built-in debugging flow, you should use 'limited' and the above guidance.

What is the guidance for task providers?

Similar to debugging, VS Code will prevent running tasks in an untrusted workspace. If your extension provides additional functionality, commands, or settings that are not part of the built-in tasks flow, you should use 'limited' and the above guidance. Otherwise, you can specify true.

How do I test Workspace Trust?

Please see this issue for current details on development of Workspace Trust. It should be up to date with how the feature is currently enabled.

[sbatten]

For those subscribed, we are now ready to share the API and guidance for onboarding to workspace trust for extension authors. This is the first time sharing the guidance to a broader audience so please post questions here and we can update it for clarity. Thanks for your engagement.

[gjsjohnmurray]

Is Workspace Trust going to land in the upcoming release?

[sbatten]

The setting to enable the feature will remain disabled by default in the upcoming release

[RandomFractals]

@sbatten thank you for providing guidance on how trusted workspaces would work.

I am concerned about your default behaviour and my expectations would be that extensions that provide web views, side bar views, pseudo terminals and commands you can run in terminal, and work with workspace files, would still function as before when this feature is released.

I would rather see this feature as opt-in for extensions that want to be enabled for trusted workspaces, and work as before for untrusted workspaces. I think the behavior you describe is the opposite.

What if I don't make changes to my extension?

As mentioned above, an extension that does not contribute anything to their package.json will be treated as not supporting untrusted workspaces. It will be disabled when the workspace is not trusted and the user will be notified that some extensions are not working due to Workspace Trust. This measure is the most security-conscious approach for the user. Even though this is the default, it is still a best practice to set the appropriate value indicating that as an extension author, you have made the effort to protect the user and your extension from malicious workspace content.

[firelizzard18]

@sbatten Is there a way to prompt the user, "To enable this feature, you must trust the workspace"? For extensions that provide actions a user can execute, simply hiding (and disabling) that functionality may be bad UX. For example, the ESLint extension - at the moment - will prompt the user to execute ./node_modules/.bin/eslint if it is present, saying something like "Do you trust this?" How should that be updated for Workspace Trust? As I read your explanation, the extension should silently disable that functionality for untrusted workspaces. As a user, I would prefer a prompt - "The extension eslint wants to do <some thing> that requires you to trust this workspace - continue?"

As another example, I have an extension that provides code lenses for profiling benchmarks (CPU/memory use). If I hide these code lenses in untrusted workspaces, I'm sure someone will report that as a bug ("the benchmark code lens doesn't show up for my workspace"). I'd like the API to include something like this:

export namespace workspace {
    export function shouldExecuteActionRequiringTrust(description: string, alertOnFailure: bool, details?: string): Promise<bool>
}

If the workspace is not yet trusted and has not yet been prompted, this would show a prompt asking if the user wants to trust the workspace. If the workspace is untrusted and alertOnFailure is true, this would show a notification that, " cannot execute because the workspace is not trusted".

[sbatten]

@RandomFractals @firelizzard18 Thanks for your engagement.

@RandomFractals you are correct in your understanding of the behavior. It is indeed opt-out, not opt-in. As this is a security feature, we must make the security-conscious decision to disable extensions that execute code and do not tell us about their trust support. We provide a user setting to override whether an extension supports untrusted workspaces locally to unblock users that have extensions that are slow to adopt. This puts the control in the hands of the user and is safe by default.

@firelizzard18 We hear this feedback. It is something we considered when coming up with the current strategy and we will keep our ears to ground on its necessity. With our current UX, we attempt to guide the user into one of two modes of operation, and they must make an explicit choice. In this way, we market the restricted mode for code browsing and navigation, but not active development since active development typically requires execution and thus trust.

We anticipate that a majority of users workflows are with trusted folders and thus should not choose restricted mode to do active development.

For this reason, the guidance is:

• If you cannot provide a coherent browsing experience in an untrusted workspace, simply set your support value to false and rely on Code to indicate that features are disabled due to this choice.
• If you can provide a solid experience for the restricted mode scenario, do so with limited or true.

[RandomFractals]

@sbatten thanks for your follow up. Sounds like the default behavior has already been decided on. I get why you'd want to configure extension activation and execution this way from security standpoint for untrusted workspaces.

What concerns me most about this approach is that it will create a potential stream of updates and some rework for extension developers similar to how we had to scramble and handle webview resources last year. I can also see a lot of users filing issues in extensions related to this new feature if configuration of this functionality is not well exposed in vscode UI for extensions and documented when you release it.

we must make the security-conscious decision to disable extensions that execute code and do not tell us about their trust support. We provide a user setting to override whether an extension supports untrusted workspaces locally to unblock users that have extensions that are slow to adopt. This puts the control in the hands of the user and is safe by default.

That part sounds like it might be ok, if you also provides proper prompts and notifications when switching between trusted and untrested workspaces.

I am not sure if @eamodio still does his monthly extension developers calls, but I think it would be great if we could do one for this functionality and you show us the whole flow of how it functions, and we hear other extension developers provide feedback that way before you realease this feature. There are only a few devs who expressed interest in learning more about this feature. So, should be manageable to get a few devs on a call for ext. devs review.

[PEZ]

Hello, thanks for providing this information and way to follow as we prepare for the roll-out.

Can you paste some screenshots showing the user facing part of it? It would help me understand what choices I make as an extension developer.

[m-hilgendorf]

How do trusted workspaces impact language servers that are not implemented directly as vscode extensions? Will their clients require configuration to receive file change updates over LSP in untrusted workspaces?

[RandomFractals]

@rebornix how do new notebooks, custom kernels, code cells, and custom notebook renderers function in these new utrunsted workspaces??? They do execute code from cells :)

[brettcannon]

@m-hilgendorf I think the security mechanism here is if your extension doesn't load then VS Code won't even have an opportunity to launch your language server or run any code of yours to connect to an externally started language server.

@RandomFractals the extensions providing notebook support will very likely simply not load in an untrusted workspace, so there won't be anything available to execute the cells.

[sbatten]

@RandomFractals you can check out notebooks and workspace trust updates here https://github.com/microsoft/vscode/issues/118584

@PEZ Since we are still polishing the UX pieces, I recommend you checkout the latest in VS Code Insiders by enabling the feature with security.workspace.trust.enabled in settings. To help you know where to look, you can expect a few components:

• A dialog on startup when opening a new untrusted folder
• An indicator in the status bar of the restricted mode (we are exploring more obvious UX currently)
• A workspace trust settings editor with lots of context, accessible via the Gear icon or clicking the status bar entry

@m-hilgendorf Without any onboarding, these extensions won't activate and thus don't have any vulnerabilities. @TylerLeonhardt has locally onboarded the powershell extension to demo how extensions using LSP could onboard. I think he can provide more details.

[RandomFractals]

super! will try that setting in insiders and run a test Rest Book to see where we at. Thanks for the pointer to the untrusted notebooks and workspaces thread.

[RandomFractals]

@sbatten am I doing this right? seems to have no effect.

[sbatten]

@RandomFractals That setting should be set to true in order to enable workspace trust (it turns on the feature but does not mean anything is trusted). It should require a restart to apply.

[RandomFractals]

tried it. do I need to actually check out and build the latest insiders v.? I set it to true, and still seeing that setting greyed out in settings.json, i.e. my insiders v. doesn't recognize it as a valid setting, and no prompts on reload.

my insiders v. info:

[PEZ]

@RandomFractals, it needs to be configured in User settings.

[PEZ]

@sbatten In testing this out a bit I notice that so far the use case in my extension that I fear would be messed up by Trusted Workspaces actually is not impacted at all.

My extension (Calva) has a command that allows the user to test Clojure out easily. It does this by creating a directory in the system Temp directory, adds a few files there, and then starts a Clojure REPL from the directory.

I am of course happy this still works without the Trust prompt, but also wondering if I rather have found a glitch in the Trusted Workspaces feature or if it is something I can assume will keep working.

[brettcannon]

@PEZ from my understanding, trusted workspaces isn't blocking what your code can do, it's blocking whether your code runs to begin with. IOW VS Code is not reaching into your Node code and blocking access to files or subprocess execution, it's providing a mechanism for extension authors to tell users, "hey, you can't use this extension with code you don't fully trust as it might do something bad".

So your extension launching without issue is (I believe) expected if you have flagged it as usable in an untrusted workspace.

[PEZ]

@brettcannon , that's how I understand it also.

I tested this with Calva flagged as not usable with untrusted workspaces. Opening a folder or workspace things behave as I expect, VS Code asks if I trust the workspace and if I answer yes, Calva is enabled, if I answer no, it is disabled.

From the enabled state there is this command that makes Calva crate directory somewhere on the computer, place some files there and open them. Regardless if there was a folder or workspace opened before or not. I was worried there would be a prompt then if I trusted this temp folder, but there isn't.

[sbatten]

@PEZ based on your description, the temp folder is under the control of the extension, it is not a product of the workspace and thus does not require workspace trust.

[PEZ]

@sbatten that is awesome. Thanks for helping me understand this distinction.

[firelizzard18]

capabilities.untrustedWorkspaces.supported signals whether your extension performs potentially unsafe operations. The only thing VSCode does¹ is load or not load your extension. Depending the value that My Extension gives:

• true - indicates that My Extension does not perform unsafe operations - VSCode always runs My Extension
• false - indicates that My Extension does perform unsafe operations - VSCode only runs My Extension in trusted workspaces
• "limited" - indicates that My Extension may perform unsafe operations - VSCode always runs My Extension

If My Extension's support for untrusted workspaces is "limited", it is the responsibility of the extension author to disable unsafe operations if the workspace is untrusted (vscode.workspace.isTrusted). ¹Additionally, in this scenario My Extension can indicate that certain configuration values are restricted - when restrictedConfigurations is provided, "the extension will not be given workspace-defined values for the given settings in an untrusted workspace."

Whether or not an operation is unsafe is something you, as an extension author, need to decide. VSCode does not do that for you.

[ThadHouse]

How does this react if there is no workspace or folder loaded? I maintain an extension that has some commands to create a project and a workspace for a user, and that currently can work just fine with no workspace loaded, but does require the extension running. Is that something I would need to mark as limited support, or are all extensions allowed to be loaded when there is no workspace loaded?

[sbatten]

@ThadHouse Currently, we treat empty workspaces as trusted. It sounds like your extension does not need workspace trust since it makes workspaces instead of relying on them. This means it should use "supported": true to work no matter what the user has said about trust or if the empty workspace behavior changes.

The above recommendation assumes that the commands you mention are the full list of capabilities. If you do have some "trust requiring" flows, I would recommend "limited"

[sbatten]

@ThadHouse thanks for the clarification. Yes, it sounds like "limited" is appropriate. To best protect the user, any code execution that comes from or is manipulated by files in the workspace falls within the scope workspace trust.

Clearly we cannot stop the user from opening a terminal and running some scripts in the workspace even after they say they do not trust it, but if an extension can avoid running it, that makes sense.

[alefragnani]

First of all, thanks providing such detailed information. The provided settings and APIs seems to be enough for my extensions (which may need fine grained control).

But I would ask a new API, which I’m not sure would be available (maybe for security reasons)

I would like to be able to know:

• The list of Trusted Worspaces OR
• A function to check whether some Workspace (which I provide the Uri) is trusted or not.

Motivation

My Project Manager extension provides a list of folders/workspaces (defined by the user) which the user can easily access, via QuickPick and Treeview. I would like to provide a different UI (icon, detailed info) for the “Untrusted” workspaces.

Is it a valid request?

BTW, maybe the Welcome Page and/or the Open Recent command could do that as well.

Thank you

[alefragnani]

Maybe I'm missing/mixing something, but it seems the debugging process of an extension, while opening trusted/untrusted workspaces as the Extension Development Host, does not respect if the extension supports untrusted workspace or not, at least in some scenarios.

My extension does not have the untrustedWorkspaces capability entry yet, then I do a simple debug:

1. Start debugging
2. Open some random folder as Extension Development Host
3. Choose Untrusted
4. The extension is active, which is weird because I didn't added support yet

Then, I close the Extension Development Host, add the untrustedWorkspaces capability entry and rebuild the extension. But now...

1. Start debugging
2. Open some random folder as Extension Development Host
3. Choose Untrusted
4. The extension is active, which is correct
5. Then I open another random folder, using File / Open command
6. And now I choose Trusted to this folder
7. The extension is not active 😕

But, if I close the Extension Development Host window and restart the debugging process, the extension now properly activates. In fact, all installed extensions does activate.

I don't thing the error is just the debugging itself, but the trust engine seems to be failing when you switch/activates new folders while debugging. I have noticed a similar extension activation issue while playing with trusting/untrusting workspaces. It seems the extensions are not properly activated/deactivated when you do this.

Is it an issue with the debugging process? I mean, is it expected that I could play with untrusted workspaces while debugging, or is not a supported scenario yet, and I must package my extension and install the .vsix file, to test the extension?

Thank you

[lszomoru]

@alefragnani, I have filed https://github.com/microsoft/vscode/issues/124182 to further investigate the issue that you have reported.

[alefragnani]

Maybe you could see this as a matter or personal taste, but how do you (VS Code team and extension devevelopers) think an extension should describe on its README, when it requires Workspace Trust, or have limitations on Untrusted Workspaces.

I mean, there is no official keyword to be used on Marketplace (which could be used on search), no badge, no shield in Marketplace (like the one you see today in Extension's View). So I wonder the better way to tell the users the extension is not fully supported.

By now, I have a few extensions which will have limitations on Untrusted Workspaces, both settings and commands, and I'm thinking to add a small Requires Trusted Workspace tag/label near each setting/command, but I'm not convinced its a good/efficient approach.

Do you (VS Code team) have plans to change the Extension's View to warn the user about the Settings and Commands which may be disabled/limited? I mean, the settings are listed in restrictedConfiguration and the commands will/can have the isWorkspaceTrusted in its when clause.

Thank you

[L13]

Hi, I'm the author of the extensions Projects and Diff Folders, that can access workspaces which are not part of the current workspace. I have the issue, that if the extensions are scanning folders and reading/writing files, I do not know if the other workspaces are trusted or not, because they are not part of the current workspace. In this case the extension info isTrusted is not really helpful. With the extension Diff Folders you can copy files and folders across workspaces, even if they are not the current workspace, which can undermined the concept, because you can copy files from an untrusted workspace into a trusted workspace. Is it possible to extend the API for trusted workspaces with the following feature?

export namespace workspace {

    export function isTrustedWorkspace (uri:vscode.Uri, showTrustedWorkspaceDialog?:boolean) :Promise<boolean>;

}

So I can ask/inform the user, that the workspace is not trusted yet and disable/enabled features depending on the result.

[hyangah]

@L13 out of curiosity - what type of attack vectors do you want to prevent by using the trust workspace API? Do the extensions copy arbitrary files and folders from external workspace into the trusted current workspace without explicit user action? Or does the extension use configuration or library/executable loaded from those folders?

[setaskin]

Hi, @sbatten and @lszomoru , I am from Live Share extension team. We have been testing workspace trust with Live Share. Since we evaluate the flow from both Host (workspace owner) and from the guest perspective, we found out that guest workspaces being always untrusted, which makes Live Share Guest debugging flow confusing. We are wondering if you can provide us an option to make guest workspace trust level to always match the host? Because, Joining a debug session on the guest side actually does not put the guest at risk at all, since the process being debugged is on the host side.

[L13]

@hyangah The extension Projects scans folders and reads on every startup of VS Code the file .vscode/settings.json in every saved workspace if available. It also writes/changes the file .vscode/settings.json in a workspace even if it is not the current workspace. So you can manage all your workspaces within one place without the need to open it. This works also if the user has never opened a workspace yet. With this API I can ask/inform the user that he has to agree if the extension should do this in a workspace. Another feature would be to provide the info in the list which workspaces are trusted or not.

The extension Diff Folders reads the file .vscode/settings.json in a workspace if available to get the value of the property l13Diff.exclude. This was a feature request by another user. You can define for each workspace with a glob pattern which files should be ignored for a comparison even if it is not the current workspace. This values will be used for the comparison and will be converted into a regular expression. It is also possible to copy files across workspaces with this extension even if they are not part of the current workspace. So you can copy files from an untrusted workspace to a trusted one. Then you have the untrusted files in the trusted workspace. This undermined the concept in my opinion. With this API the extension can inform the user that he is copying files from an untrusted workspace to a trusted one.

[alefragnani]

@L13 , I have asked a similar API ( tracked in #123495), but after a few discussions the VS Code team decided to abandon the idea, for now.

Add your comment/upvote, so the team could reevaluate and maybe reopen the issue in upcoming releases.

[aeschli]

@setaskin I created https://github.com/microsoft/vscode/issues/124971 to look at the Live Share 'Join as Guest' flow.

[Colengms]

@sbatten Using 'limited', I've noticed that VS Code will restart the extension when a folder is removed from the trusted list. It would be nice to be able to handle un-trusting without having to be restarted. Also, restarting the extension might be a desirable way to deal with becoming trusted as well. Would it be possible to support both an event or restart, for both? i.e.

capabilities:
    untrustedWorkspaces:
        { supported: true } |
        { supported: false, description: string } |
        { supported: 'limited', description: string, restrictedConfigurations?: string[], restartOnTrusted?: boolean, restartOnUntrusted?: boolean }

I figure restartOnTrusted would default to false, and restartOnUntrusted would default to true.

export namespace workspace {
    /**
        * When true, the user has explicitly trusted the contents of the workspace.
        */
    export const isTrusted: boolean;

    /**
        * Event that fires when the current workspace has been trusted.
        */
    export const onDidGrantWorkspaceTrust: Event<void>;

    /**
        * Event that fires when the current workspace has been un-trusted.
        */
    export const onDidRevokeWorkspaceTrust: Event<void>;
}

Or maybe a single event.

    export const onDidWorkspaceTrustChange: Event<boolean>;

Or, if letting extensions handle un-trusting is somehow a risk, perhaps just add an option for restart when trusted? :)

[lszomoru]

@Colengms, thank you very much for your feedback. Currently all extensions are running in a single extension host independent of their support for untrusted workspaces. When a workspace transitions from trusted -> untrusted, we do not have the capability to individually unload extensions that do not support untrusted workspaces hence we have to restart the extension host in order to safely unload all extensions, and then only load the ones that support untrusted workspaces..

[dummdidumm]

I maintain a VS Code extension which has a setting which is currently marked with "scope": "application", meaning it can't be overwritten at the workspace level. Is there a way to lift this restriction for people who use newer versions of VS Code which mark the workspace as trusted while maintaining backwards-compatibility for older versions of VS Code in the sense of "keep "scope": "application""? I want to avoid bumping the minimum required VS Code version for the extension.

[sandy081]

I do not think there is a way other than bumping vscode engine version.

[vadimcn]

@sbatten What is the motivation behind asking debug extensions to mark themselves as safe for untrusted workspaces?
Debugging untrusted code is among the least safe things one could do. Wouldn't it make more sense to mark debug extensions as not supported for untrusted workspaces, just to be double-sure?

[bwateratmsft]

@sbatten What is the motivation behind asking debug extensions to mark themselves as safe for untrusted workspaces? Debugging untrusted code is among the least safe things one could do. Wouldn't it make more sense to mark debug extensions as not supported for untrusted workspaces, just to be double-sure?

@vadimcn I think that's covered already. From the description in this comment:

What is the guidance for debug extensions?

VS Code will prevent debugging in an untrusted workspace. For this reason, generally, debugging extensions do not need to additionally require trust and should select true for the supported property. However, if your extension provides additional functionality, commands, or settings that are not part of the built-in debugging flow, you should use 'limited' and the above guidance.

So I don't think debug extensions will be able to debug in an untrusted workspace, no matter what they mark themselves for.

[vadimcn]

Yes, I've seen that comment. I still don't understand the motivation for asking debug extensions to set "supported": true. Is there any behavioral difference between this and "supported": false?

[bwateratmsft]

That makes sense. I think it will have to be up to extension authors to determine based on the guidance above. If the only thing an extension provides is debugging, I think that is functionally equivalent to "supported": false, but there could be other features that are safe in an untrusted workspace (or features that aren't, and "supported": "limited" is appropriate).