Extensions are only loaded if they are allowed by a blocklist

[jfoley]

This PR begins to address #84756.

This PR includes functionality to allow certain extension publishers or to disallow certain extension publishers. It also includes the ability to disallow particular extensions.
In order to use it, add the following to your settings.json:

"extensions.blocklist": {
		"allowedPublishers": ["my-trusted-publisher"],
		"allowedPackages": [],
		"prohibitedPackages": []
	}

Attempting to install a forbidden extension will result in an error notification letting the user know that the extension is prohibited by local policy.

We wanted to open this PR to gather feedback and see if we are on the right track.

[msftclas]

All CLA requirements met.

[jfoley]

Hello, we were wondering if we might be able to get an update on this PR. We have a couple of high-profile projects that are awaiting feedback on it. Thanks!

[sandy081]

Looks like you picked up a feature which needs further discussions. Need to see how useful it is for all users? Can you also please let us know the use case behind this?

If I remember, I think I suggested to start with following feature

The policy would include a setting whether to allow side-loading of extensions (as VSIX files)

[mike-myers-tob]

Looks like you picked up a feature which needs further discussions. Need to see how useful it is for all users? Can you also please let us know the use case behind this?

If I remember, I think I suggested to start with following feature

The policy would include a setting whether to allow side-loading of extensions (as VSIX files)

Hi! I work with John, I can elaborate on the use case here.

VS Code is a popular development environment, including among employees of medium/large companies, so it is installed on many (managed) company laptops and desktops. Company security teams seek to track and manage the software installed on company systems, but VS Code is an extensible application with a built-in extension marketplace. Users, even those without administrator rights, can freely choose to install any extension into VS Code. Those extensions are sandboxed, but are unsigned and managed in a user-owned directory. Extensions are installable through an extension marketplace controlled by Microsoft, but enterprise security teams want a more granular ability to mitigate risk and exposure to unapproved software on their fleet. Others before us have filed related issues in #52116 and #33185

Because of VS Code's robust extensibility, we have been approached by multiple customers asking us to develop enhancements to VS Code that make it more "manageable" within the corporate environment. The first step @sandy081 suggested in the last discussion was to create a policy to control sideloading, but our customers have told us that the most desired use case for them is controlling what the user can install from the marketplace beginning with the basic whitelist/blacklist by extension ID.

We'd like to start there, and get feedback on the feature and our implementation of it. Any response is much appreciated and we want to work with all parties to adapt a solution.

[sandy081]

I understand your requirement and this is under discussions with Marketplace team.

• Feature Request: Support for private marketplace/gallery #21839

Hence I would not suggest to introduce hacks or workarounds for a specific user.

[dguido]

@sandy081 #21839 doesn't appear to have perfect overlap with this PR. That issue describes allowing enterprises to host their own extensions. This PR addresses companies that want to control which extensions an employee can install from the public marketplace.

Also, the intention was to PR production-quality/ready code, not a "hack." We think our solution is more than maintainable, and it goes far beyond Stripe that has asked us to help implement it.

Can you please re-open this issue so we can continue to refine it with the team at Microsoft? We will get in touch with @prashantvc in the meantime. Thanks.

[sandy081]

That issue describes allowing enterprises to host their own extensions. This PR addresses companies that want to control which extensions an employee can install from the public marketplace.

They look similar to me. Is not that enterprises want to have their own set of extensions (private or hosted from marketplace) available to their users?

It might not be a hack but it seems to be a workaround for the problem that has to fixed at another level. Ideally it's about configuring marketplace to serve only restricted extensions.

Also I do not think the provided fix/solution here will help because its always possible for users to modify settings.

I would recommend to continue discussion in the main issue - #84756.

[dguido]

They look similar to me. Is not that enterprises want to have their own set of extensions (private or hosted from marketplace) available to their users?

It might not be a hack but it seems to be a workaround for the problem that has to fixed at another level. Ideally it's about configuring marketplace to serve only restricted extensions.

Also I do not think the provided fix/solution here will help because its always possible for users to modify settings.

1. Enterprises we spoke with would like to avoid having to host additional infrastructure to support yet-another-development-tool.
2. They already have endpoint controls -- JAMF, osquery, Santa, etc -- that would make it simple to deploy and enforce this setting.
3. Providing guardrails around the public marketplace provides a better end-user experience.

If you also create a feature to let enterprises host their own, internal marketplaces, then I think that would be complementary but not a replacement to what we developed.

I would recommend to continue discussion in the main issue - #84756.

We will. But in the meantime, please re-open the PR. We'll continue working on it while we're discussing this approach with the relevant PMs. Thanks.

[sandy081]

Reopened as per user request but assigning this to PMs for further discussions.

[chrisdias]

Per #84756 (comment) this is a good topic on our Roadmap, but this PR is not something we can accept right now as the scope is too narrow (only applies to settings.json). Once we have a comprehensive design we can start to accept PRs on this.