Private marketplace support

[isidorn]

VS Code customers have a need for a private marketplace. Motives:

• They have extensions which they do not want to share publicly (they only make sense for their setup)
• Strict security requirements: want more control over what is available
• Still want all the benefits of a marketplace (nice integration with VS Code, auto update)

[ttutko]

Just wanted to add something maybe not completely captured in the motives:

• Development performed on a 100% air-gapped (no internet access) system

[GitMensch]

I'm confused to see this in this repo - because the point is to NOT connect to the vsmarketplace.
This leaves it open to either host an instance of the vsmarketplace somewhere or use one of the (2?) existing vsix providers.

So, is this an issue to track "give people the option to host an own instance (with the need to do so also when disconnected from the internet) somewhere"? If not: How does it apply to the vsmarketplace?

In both cases vscode needs an option to setup a different URL/Path to the marketplace (which is a closed PR at microsoft/vscode#129764).

[ttutko]

@GitMensch I think you have a very valid point but I think it can be seen as an issue that exists for both repos. On the marketplace side, I'd like to see either a tool or some sort of api specs documented that allows for the creation of an offline mirror of the marketplace without having to reverse engineer api calls as well as self-hosting a mirror.

One specific thing to keep in mind with this offline mirror is that some extensions download additional items from the web when first activated and that makes things even more painful for those of us who have to work completely offline. For example, the remote ssh extension and the c# extension, both from MIcrosoft. In the former's case, they provide no single download for offline use that I'm aware of and it's a bit tricky to get working. For the latter, they actually display a log message saying "Go here and download the offline package and follow the instructions" which certainly helps.

On the VSCode side of things, yes, I think it should allow you to point it at a different url for the marketplace or perhaps multiple urls. However, if you are on a closed network that you control, it's easy to make the existing marketplace url point to your own server.

[GitMensch]

@ttutko The current options that I know to work for this is applying microsoft/vscode#129764 and point it to a self-hosting instance of Eclipse Open VSX, already done in "closed" environments. Note: Doing so prevents searching for extensions using file type associations, but other than that I haven't seen any issues.

[ttutko]

@GitMensch Thanks! I wasn't aware of Eclipse Open VSX but have used https://github.com/LOLINTERNETZ/vscodeoffline so far which also seems to work well except in cases of extensions that download additional stuff upon activation as I mentioned above.

[GitMensch]

Interesting, I wasn't aware of that, so were on 3 possible vsix providers already.

[ghost]

@GitMensch What is the third provider? I only saw two mentioned so far in this thread: Eclipse Open VSX and LOLINTERNETZ/vscodeoffline. Did I miss something? Or maybe you're referring to a (so far vaporware) solution from Microsoft?

[GitMensch]

Not sure any more. There's at least:

• the offline thing
• hosting a private "marketplace" and:
  • point product.json to it
  • apply the referenced patch to vscode, then set environment variable(s) to point to the local marketplace

[Kingwl]

Looking forward on this one.
And happy to working on this If I may.
AFAIK, many company has already implemented their own private marketplace without any standard.
This is not good for the eco system.

[AndersHogqvist]

bump!

[lextm]

Open VSX

• As that key PR is not approved by VSCode team, you have to hack VSCode installation to connect to self hosted Open VSX server instance, which violates Microsoft EULA.
• It also lacks a rich set of deployment options (for example it natively just supports a few storage options).
• Open source.
• Community support.

https://github.com/eclipse/openvsx

vscodeoffline

• You have to hack your own DNS/certificate system to fake all those Microsoft domains.
• Mirroring extensions can violate their licensing agreements (as not all of them are open sourced or distributed under open source licenses).
• The only deployment option is via Docker image.
• Source code availability is unknown.
• Community support.

https://github.com/LOLINTERNETZ/vscodeoffline

Scarborough for VSCode

• Full compliance to VSCode EULA and no hack.
• Full integration with VSCode and similar extension search/installation experience (such as auto update).
• Rich deployment options and integration with common enterprise infrastructure (such as storage/workflows).
• Assistance on internalizing of VSCode extensions (resolving issues such as external downloads).
• Commercial support and other customization options.

If you want to learn more about Scarborough for VSCode, you can send inquiries to [email protected].

https://www.scarborough.market

[GitMensch]

Nice advertisement - but if you can't provide any details about the following it is actually a wrong statement with the seemingly intention of bad reputation:

you have to hack VSCode installation to connect to self hosted Open VSX server instance, which violates Microsoft EULA

The MS EULA does not apply at all if you build vscode from source - because then you only have free or at least open source used. And I fail to see how it violates the MS EULA to adjust product.json from an installed Visual Studio Code (which is a MS binary only distribution of vscode + x + telemetry), and at least in the past there was official documentation to adjust it for not checking for updates and other stuff.

[lextm]

I definitely understand how eager you'd like to promote open source solutions out there and really appreciate your attempt to make Open VSX an alternative to Microsoft Marketplace. That shows your passion and courage. However, software licensing is always a tricky part of commercial open source projects.

By building from source and apply the patch you made, you not only free yourself from MS EULA on VSCode, but also deprive yourself from using many of the extensions and their related bits, because you are no longer using VSCode (the strict term, the MS binary only distribution) but your personal fork.

For example,

• Pylance extension has very strict license terms so you can only use the official MS binaries, https://marketplace.visualstudio.com/items/ms-python.vscode-pylance/license
• Microsoft C/C++ extension requires the same https://marketplace.visualstudio.com/items/ms-vscode.cpptools/license
• vsdbg as dependency of several extensions (like C#) requires the same.

That's why you cannot find certain extensions on Open VSX, and why other forks derived from MS VSCode repo suffer the same.

As you have been working with open source for years, I guess you know how many companies are using similar strategies, like Google's Chrome Enterprise.

If an enterprise does not want to lose any key extensions (and other benefits from VSCode EULA), does not want the burden to build everything from source and manage VSCode fork, then using binary distribution from Microsoft shouldn't be a surprise.

Hope that's all the details you expected.

[GitMensch]

OK, so to summarize: if you use any vscode build that is not from MS (named "Visual Studio Code" binaries) and use some of the MS extensions you break the EULA of those extensions.
In this case: it doesn't matter if you manually download them from the MS marketplace or use Project Roundhouse - whatever unfree stuff that is.

Your false claim was using OpenVSX breaks MS EULA - which is obviously totally not the case.
When using the public installation hosted by Eclipse Foundation you won't get any extensions that have an EULA like the MS ones - which is the reason those extensions are not found there, and when using a self-hosted instance (which is very reasonable for "local" environments like closed labs or closed developer environments) you (hopefully) won't distribute those extensions in there.

And yes - I don't use those MS extensions but stay with the "old", free Python extension, use free C/C++ language extensions, debuggers (native-debug is very worth a look, it 'only' does not contain latest debugger features because of missing contributions, but works fine for GDB/LMDB and seemingly Mago based debuggers).
There is no reason to use a proprietary "other" marketplace either, much less when advertisements for it came with false accusations of breaking the EULA. (which I assume was not your intention, you may want to edit your post 2 above if it wasn't; no need to discuss that here otherwise, this is about private marketplace support [in my case for closed lab and dev environments]).

[lextm]

"In this case: it doesn't matter if you manually download them from the MS marketplace or use Project Roundhouse - whatever unfree stuff that is" is false. The actual delivery method (Microsoft Marketplace/manual installation from .vsix files/Project Roundhouse) does not break the EULA of those extensions, as finally the extensions are installed to Microsoft VSCode, not any other forks.

If you review all my words above, you can see that I only claimed a single case that violates of VSCode EULA. To make it clearer,

1. You install VSCode Microsoft distribution.
2. You apply any trick (detailed/hinted in your PR or any other internet posts) to force it to connect Open VSX, either the public instance hosted by Eclipse Foundation or the self-hosted instance by any organization themselves.

You can assert whether that's a "false claim" by analyzing VSCode EULA.

It's obviously from your perspective that "there is no reason to use a proprietary "other" marketplace either", because (I summarized from your words)

1. You target closed lab and dev environments
2. You rely on a small set of VSCode extensions
3. You probably build from source and run your own fork and are happy with that approach as you have extensive domain knowledge

but many that ask for private VSCode marketplace are in different situations. Some of the typical requirements are,

• Strict compliance to all EULAs (VSCode or extensions)
• Integration with their internal workflows and systems (account/asset management for instance)
• Premium support contracts

So a hassle-free solution like Project Roundhouse has its reasons to stay, and open source solutions with limited community support fall short.

This should be a place for meaningful discussions around private marketplace with all feasible options (open source or not) for whoever needs help. My company is already in close contact with customers and I posted here to see if more people are interested.

[ghost]

@isidorn Hi! how are you? Hi all! So... that's a great idea, I even thought about it before. Glad you wrote it, my idea would be to have a bitcoin payment inside VScode for the plugins

[ghost]

This feature could be for premium users or for free users with some limitations.

[z-juln]

This is my solution: https://juejin.cn/post/7141662937420136479/

[lextm]

While this post (in Chinese) claimed to be a "solution", it didn't provide evidence on whether it resolves specific requirements like per platform package support, remote development setup support and etc.

This is not the first attempt to use NPM mechanism to store VS Code extensions, but limitation of that mechanism remains.