[proposal] Set up a central list of deprecated, malicious and pre-release extensions

[filiptronicek]

Since VS Code 1.68, Microsoft maintains a list of deprecated and malicious extensions for their Marketplace. This list is very helpful for keeping users off of unsafe extensions, while ensuring a good experience with suggestions on extensions they should migrate their deprecated ones to.

At Gitpod, we discussed the idea and settled on not maintaining our own list, but rather introducing one that would be owned by Eclipse while at the same time being maintained by the community along with maintainers of projects like VS Codium, Gitpod, Theia or Code-server. I would love an approach similar to the one employed by https://github.com/open-vsx/publish-extensions, where the community engages itself in a lot issues and PRs.

Implementing such a list would require every fork of VS Code adopting it to change the product.json file for the new extensionsGallery.controlUrl property. This means it's independent from the Marketplace and can be any URL.

We have implemented a repository which we will be using in Gitpod after https://github.com/gitpod-io/openvscode-server/pull/380. It is located in https://github.com/gitpod-io/gitpod/blob/main/components/ide-proxy/static/code/marketplace.json.

Further details can be found in the links below.

• Gitpod's RFC [Notion]
• https://github.com/gitpod-io/gitpod/issues/10847
• https://github.com/microsoft/vscode/pull/149697

[amvanbaren]

From https://github.com/gitpod-io/gitpod/issues/10847#issuecomment-1164488612:

Filip suggested to be in openvsx github repo and just use github url to the json file so we are not impacted by they deployment schedule.

I like this solution.

I was briefly thinking about whether upstream support should be added, but I don't think so. That would make it too complicated to find out which extensions are malicious, deprecated, etc.

Is there a JSON schema for the marketplace.json file? It would be nice to set up a CI job that validates each commit to the file.

[filiptronicek]

@amvanbaren,

I was briefly thinking about whether upstream support should be added, but I don't think so.

In the future, I can see us being able to serve a "merged output" of one origin and one upstream file, but do not think we should be considering that in the first iteration of this.

Is there a JSON schema for the marketplace.json file?

There's no official JSON schema AFAIK, but there are TS Types, from which I made a JSON schema for us to use. I agree something that could validate PRs would be great there 💯!

[amvanbaren]

Some other questions popped up as I thought about this a little more:

How is it determined that an extension is malicious, deprecated, etc.? I can't access the RFC. Is it detailed there?

Should the openvsx server also perform actions? This is most likely beyond the initial scope, but to give a couple examples:

• Throw an error if a user tries to publish a new version of a malicious extension.
• Return a warning if a user publishes a new version of a deprecated extension.
• Open a Github issue when an extension isn't actively maintained, so that it can possibly be marked as deprecated.

[filiptronicek]

How is it determined that an extension is malicious, deprecated, etc.?

Unsure about malicious extensions, but it is mostly about extension that do malicious like steal some user data, implement some back door or behave as any other malware. These are then removed from the Marketplace, but this doesn't remove the extensions from the users who have downloaded it. The marketplace.json file takes care of that by warning users next time they start VS Code. This also prevents users from downloading a malicious extension all together. See that no "Install" button is present:

For deprecated extensions, I only have some assumptions about the steps Microsoft took:

1. There are already some deprecated extensions on the store. A lot of the time they have [DEPRECATED] in from of their name but aren't treated differently in the Marketplace UI. This is something they will maybe do (https://github.com/microsoft/vsmarketplace/issues/23). They have taken about 70 of the biggest deprecated ones and added them to the list initially.
2. Now they opened it up to the community and let people add more on https://github.com/microsoft/vscode-discussions/discussions/1.
3. In the future I can see them maybe even adding this to the Marketplace itself, but who knows 😆.

Thanks for bringing this up, @amvanbaren, I'll add that to the RFC.

Should the openvsx server also perform actions?

For the actions taken by the ovsx server, I really like all 3 of your examples, although I think that this is indeed not in scope of this initial RFC, since it's just for kicking things off, but awesome ideas for the next iteration(s)!

[kineticsquid]

Another related issue:https://github.com/EclipseFdn/open-vsx.org/issues/1412

[kineticsquid]

Summarizing a call today with @filiptronicek and @waynebeaton:

• Filip will contribute input from Gitpod, both lists of extensions and schema documentation
• John will add input from requests to EF
• John will update documentation to include the schema and to provide instructions to extension publishers and users for how to use and update the lists.
• Once the lists and documentation are in place, we'll publicize the list and processes:
  • Blog
  • open-vsx.org banner
  • Cloud DevTools and Open VSX working group steering committees
  • Theia developer community
  • Coder, VS Codium, forkers of VS Code repo

@amvanbaren FYI

[kineticsquid]

There is follow on work needed to visualize the list both on open-vsx.org and in Theia.

[kineticsquid]

@filiptronicek Any news on this?

[filiptronicek]

I am happy to report back, having applied the latest updates from upstream, that the extension control file is now maintained in the publish-extension repository. I am also working on automating updates to it so that we can maintain it more effectively.

https://github.com/open-vsx/publish-extensions/blob/master/extension-control/extensions.json

cc @kineticsquid

[kineticsquid]

@filiptronicek Thanks and sorry for the delay in responding. IIRC, we currently don't reflect the status of these deprecated extensions in the UI, right?

[filiptronicek]

IIRC, we currently don't reflect the status of these deprecated extensions in the UI, right?

Yes, we have not made any mentions of the list in the openvsx codebase.

[kineticsquid]

@filiptronicek @mbarbero @amvanbaren What do you think we should do, understanding that development would likely be required that we'd have to prioritize?

It seems to me that anything that shows up in the malicious list doesn't get displayed or returned in an API calls. Why wouldn't we immediately remove the offending versions?

The deprecated list seems like we'd want to show them with some UI 'deprecated' treatment and a pointer to the replacement if there is one.

[filiptronicek]

It seems to me that anything that shows up in the malicious list doesn't get displayed or returned in an API calls. Why wouldn't we immediately remove the offending versions?

This process should be that we first remove the extension from the registry, then update the list, meaining that the malicious list entries won't be of any use to the website. The field is there primarily for VS Code clients which may have the extension installed and would act accordingly.

The deprecated list seems like we'd want to show them with some UI 'deprecated' treatment and a pointer to the replacement if there is one.

💯

[mbarbero]

I 👍 everything that can help openvsx offering more security to end users.

This process should be that we first remove the extension from the registry, then update the list, meaining that the malicious list entries won't be of any use to the website. The field is there primarily for VS Code clients which may have the extension installed and would act accordingly.

This sounds like a very good first step.

[amvanbaren]

This process should be that we first remove the extension from the registry, then update the list, meaining that the malicious list entries won't be of any use to the website. The field is there primarily for VS Code clients which may have the extension installed and would act accordingly.

So the process would be similar to a namespace change or extension removal?

• Person opens issue to report malicious extension.
• Admin flags extension as malicious in System.
• System removes extension.
• System adds extension to malicious list.

[amvanbaren]

The deprecated list seems like we'd want to show them with some UI 'deprecated' treatment and a pointer to the replacement if there is one.

The VS Marketplace prepends [Deprecated] to the extension title.

In VSCode it prepends [Deprecated] to the extension title and points to a replacement.

[amvanbaren]

Should deprecated extensions be discounted or excluded in search results?

[filiptronicek]

The VS Marketplace prepends [Deprecated] to the extension title.

From personal experience and from some past public conversations with the VS Code team they said they are not using any of the data from the deprecated extension list in the Marketplace. I believe the name changes are done by extension authors themselves, because there are extensions such as jetmartin.apicurio which do not have this title update on them.

[filiptronicek]

This process should be that we first remove the extension from the registry, then update the list, meaining that the malicious list entries won't be of any use to the website. The field is there primarily for VS Code clients which may have the extension installed and would act accordingly.

So the process would be similar to a namespace change or extension removal?

* `Person` opens issue to report malicious extension.

* `Admin` flags extension as malicious in `System`.

* `System` removes extension.

* `System` adds extension to malicious list.

I'm aligned on steps 1-3, but because because the list is rather a file hosted in a separate repo, the best approach IMO would be to raise an automatic PR against the file contributing the new malicious entry.

[amvanbaren]

I'm aligned on steps 1-3, but because because the list is rather a file hosted in a separate repo

Ok, will Open VSX be the only one raising PRs or should Open VSX periodically pull the file and check for changes?

[filiptronicek]

@amvanbaren we expect the community to be raising PRs about deprecated extensions and there may be some entries under malicious that we adapt from the list from Microsoft with a separate CI job. Open VSX could then potentially pull this list periodically to have bidirectional sync of malicious extensions.

[amvanbaren]

@filiptronicek In that case I think it's easier to have the publish-extensions repo as the main source of truth. open-vsx.org and openvsx issues related to deprecated or malicious extensions should be redirected to the publish-extensions repo.

Open VSX can check for changes or a bot account can push the changes to Open VSX when the file is updated.

[filiptronicek]

@amvanbaren sounds good and less complicated 👍

[kineticsquid]

@filiptronicek @amvanbaren @mbarbero Summarizing:

• Official list exists in publish-extensions here
• Requests to update can come in the form of PRs or issues in publish-extensions, or issues in either of the other two repos.
• If the latter, we redirect to an issue in publish-extensions.
• There's a separate piece of work to bring publish-extensions (or at least a fork of it) under Eclipse Foundation control.
• update.ts updates the extensions.json file of problematic extensions based on upstream changes.

Questions:

• Do we need an action in publish-extensions to run update.ts?
• I'm not sure I understand these steps:
  • Admin flags extension as malicious in System.
  • System removes extension.
  • System adds extension to malicious list.
• As an admin how would I flag a malicious extension in System beyond submitting a PR to update extensions.json?
• Given that this is so infrequent, does it make sense to automate this or would it just be simpler for me as admin do the removal?

[filiptronicek]

Do we need an action in publish-extensions to run update.ts?

We should. I think it's fair to have it run on a weekly schedule and raise PRs which we can easily review and merge.

[amvanbaren]

I'm not sure I understand these steps:

Admin flags extension as malicious in System.
System removes extension.
System adds extension to malicious list.

These steps are no longer relevant. Under the new process Open VSX pulls in the list (or gets notified of changes). No Open VSX admin action required.

[filiptronicek]

Hey folks, I am happy to say that Gitpod has now been using the official extension control manifest in its VS Code Browser implementation for quite some time without any issues.

There also is now a dedicated JSON schema we've made to support the adoption of the file and updates are conducted regularly to reflect the state of the upstream (so far, we've received no requests to add anything exclusive to https://open-vsx.org).

I am also happy to support testing for any features that may land on the https://github.com/eclipse/openvsx/ repo, so that we can make the file even more useful and convince even more VS Code forks to adopt it.

cc @kineticsquid @amvanbaren

[kineticsquid]

@filiptronicek Nice work! I see a search section. How's that intended to be used? @amvanbaren Were you working on UI enhancements to mark deprecated extensions?

[filiptronicek]

@kineticsquid the search section we can get a bit creative with the surface extensions to users they probably want to install depending on some keyword. Microsoft for instance uses it to push some of its extensions as preferred results in VS Code, for example if you search for "ai", the GitHub Copilot extension will be at the top, even though it does not best fit the search (by title, description, downloads, ratings, etc.).

There is no need for us to add any extensions, but it's good to keep it in mind as a tool in our tool belt (for instance for promoting open-source alternatives to extension exclusive to Microsoft's Marketplace).

[amvanbaren]

Yes, I used a grayscale filter to mark deprecated extensions:

[kineticsquid]

@filiptronicek Understood, makes sense.

@amvanbaren The UI treatment looks good. A couple of questions. I see in extension-control/extensions.json different types of entries. E.g., "abusaidm.html-snippets": true.

Also:

        "auchenberg.vscode-browser-preview": {
            "disallowInstall": false,
            "extension": {
                "id": "ms-vscode.live-server",
                "displayName": "Live Preview"
            }
        },

and:

        "Shan.code-settings-sync": {
            "disallowInstall": true,
            "additionalInfo": "Please use the built-in [Settings Sync](https://aka.ms/vscode-settings-sync-help) functionality instead."
        },

How do the UI treatments differ?

Also, before we make this live, we'll need to prepare some documentation on what folks need to do to deprecate and I think we'll want to include a new banner message, https://github.com/EclipseFdn/open-vsx.org/issues/2750.

[amvanbaren]

How do the UI treatments differ?

disallowInstall indicates whether the UI should show a download button for the extension. extension shows a link to a replacement extension in the UI: "This extension has been deprecated. Use ${replacement} instead." settings and additionalInfo are not used in the UI.

When it's just a boolean ("abusaidm.html-snippets": true), it means the extension is deprecated. The extension is still downloadable ("disallowInstall": false) and no link to a replacement is given.

[kineticsquid]

Understood, thanks.

[kineticsquid]

Related question to updating the UI. Should the /extension API return a value to indicate an extension is deprecated? I checked and the VS Marketplace API does not seem to return deprecated information.

[filiptronicek]

I think we shouldn't expose that info through the API just yet and just let users query the control manifest directly if they want that information. Microsoft leaves these two components (the web marketplace and control manifest file) decoupled and does not integrate their list into the API or the interface.

[amvanbaren]

@kineticsquid The webui uses the API to get the extension data. /api/{namespace}/{extension} /api/{namespace}/{extension}/{version} /api/{namespace}/{extension}/{targetPlatform} /api/{namespace}/{extension}/{targetPlatform}/{version} /user/extensions /admin/extensions

[kineticsquid]

Before we go live with this, we'll need to provide documentation on how to deprecate an extension.