Open mike-myers-tob opened 4 years ago
Appreciated for the detailed description of your requirement. To start with, one of the requested features is already supported. Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update
. User can pin to a specific version of an extension. Some of the features are not common and not frequently asked like disabling side loading, cooling off period.
I would say overall it is a big feature and generally not considered for external contribution. But if you are super keen on this, you can think of going with one by one.
Hi Sandeep,
Thank you for that context. It's quite helpful. If we split this into three contributions (allowlist, denylist, and cooling off period) do you think that these features would be approved?
Thanks, Roman
On Mon, Nov 18, 2019 at 4:17 AM Sandeep Somavarapu notifications@github.com wrote:
Appreciated for the detailed description of your requirement. To start with, one of the requested features is already supported. Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update. User can pin to a specific version of an extension. Some of the features are not common and not frequently asked like disabling side loading, cooling off period.
I would say overall it is a big feature and generally not considered for external contribution. But if you are super keen on this, you can think of going with one by one.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/84756?email_source=notifications&email_token=AL6TDYMM4D2TVNYGCUXTVO3QUJTRXA5CNFSM4JNEKII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEJ5SLQ#issuecomment-554948910, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL6TDYK2CXLUSGI3BW2JPODQUJTRXANCNFSM4JNEKIIQ .
Depends on how complex each feature is going to be. But PRs are always welcome.
@sandy081 what would you recommend we do in order to ensure that our contribution is accepted and merged in due time? I see there are many PRs going back several years, so some PRs are not welcome. We just want to know if these are specifically features that would be merged, if we completed a PR.
You can start with
The policy would include a setting whether to allow side-loading of extensions (as VSIX files)
Providing organizational level security is on our 2020 roadmap (Make consumption of extensions more secure...) so this is a good topic, thank you.
As @sandy081 mentions this is a significant feature area that we want to allocate time and resources for to do a comprehensive design and implementation, which makes it difficult right now to accept external contributions.
Per our roadmap, you can expect that we will look at this over the next 6-12 months.
Hello, @chrisdias my customer is also keen to see this available as they rolled out the ADS in their corp but they want to control what users can install and managed centrally by policies. So that users dont miss use the extensions for data exfiltration or code leakage. Any further update on this would be great as the last comment is 2.5 yr old , i like to know what is the latest. Thanks
Hello.
I represent a small company 50-100 employees, with an internal development team comprising approx. 10-15 developers, testers and business intelligence users who all use Visual Studio Code. We have two goals that I'd like to address: to obtain a degree of consistency of extensions installed across devices, and the facility to control that centrally. To that end I had the bright idea of creating a feature request only to learn that this request already exists (and has for three years 🙄😄). Nevertheless, I was asked to share our use case here :).
Having an allow-list policy would enable us to limit the set of extensions that can be installed across the workplace in a simple-to-manage manner, however a model similar to Firefox's ExtensionSettings policy would allow us to explicitly control the entire set (noting that only the 'installation_mode' and possibly 'blocked_install_message' properties might be appropriate here).
Firefox example
{
"*": {
"blocked_install_message": "Custom error message.",
"install_sources": ["https://yourwebsite.com/*"],
"installation_mode": "blocked",
"allowed_types": ["extension"]
},
"uBlock0@raymondhill.net": {
"installation_mode": "force_installed",
"install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
},
"https-everywhere@eff.org": {
"installation_mode": "allowed"
}
}
Possible VS Code example
{
"*": {
"blocked_install_message": "This extension has been blocked by your organisation.",
"installation_mode": "blocked"
},
"ms-python.python": {
"installation_mode": "force_installed"
},
"vscodevim.vim": {
"installation_mode": "allowed"
}
}
To date we have addressed our requirements by installing extensions to a non-user-writable location and setting the (undocumented - I believe) VSCODE_EXTENSIONS
environment variable to point to that folder - but this is brittle at best.
Thanks for your time.
I created a duplicate issue ( https://github.com/microsoft/vscode/issues/170840 ), I'll bring what I wrote there to this discussion.
As the VSCode marketplace does not seem to be sufficiently regulated from a security point of view:
It would be great with ADMX policies for specifying extension policies, like:
ATM, update mode seems to be the only thing one can control with VSCode.
What is the latest on this on Microsoft's end? This previous comments reads as though it was actively being looked at being placed on the roadmap, is that still the case?
Its 2024, is there an update on this? This is a security issue that needs to be addressed.
Here two years later, I see it was accepted onto the backlog but can we get a timeline as to when this will be out or if it is already available
Is there any priority for this feature? Malicious plugins are a great security risk for our company and we have no way to combat this, short of not allowing VSCode as an installation on our development teams machines.
@xNarnia until something better gets implemented can you use the information at https://code.visualstudio.com/docs/setup/network#_common-host names to block all extension installation direct from Marketplace?
Posting to add further weight to the urgency of this:
"Microsoft's lack of stringent controls and code reviewing mechanisms on the VSCode Marketplace allows threat actors to perform rampant abuse of the platform, with it getting worse as the platform is increasingly used."
This feature request is on our roadmap and I expect it to land in the next 6 months.
Is there any priority for this feature? Malicious plugins are a great security risk for our company and we have no way to combat this, short of not allowing VSCode as an installation on our development teams machines.
You do have another option when you are in control of the installations: drop the marketplace entry points from product.json or replace them to an endpoint you control, for example an OpenVSX instance uploading only the extensions there that are validated.
Especially when dropping the endpoint and controlling the installations of vscode, you may want to extract extensions into the vscode installation (below resources\app\extensions) - they will be shown as builtin and work fine.
Of course this only works if you prevent installing from vsix - @isidorn a setting in product.json to prevent that (both from command line and from UI) would be very useful.
To add some fuel to the fire: https://medium.com/@amitassaraf/the-story-of-extensiontotal-how-we-hacked-the-vscode-marketplace-5c6e66a0e9d7
It would be very nice if we could whitelist extensions by author. So we could for example whitelist all extensions by Microsoft.
We use devcontainer.json to have several extensions pre-installed. It would be nice to forbid users installing extensions in general without breaking installation at Devcontainer build time.
Is there any update on this? What are folks doing to prevent developers from installing bad extensions from the marketplace today?
My last comment still holds true https://github.com/microsoft/vscode/issues/84756#issuecomment-2157964224 We are aware of this, and I expect us to have something in the next couple of months.
That is great, thanks @isidorn for the response, looking forward to testing out this feature.
Hello! We (Trail of Bits Engineering Team) have been asked by one of our clients to contribute a feature to Visual Studio Code, and before we even begin we wanted to introduce ourselves and our plan and get feedback on (or approval for) our plan from the core maintainers of this repo. The proposed changes are to how the editor interfaces with the Extensions Marketplace, so it will only be useful if the changes can be upstreamed. In fact, we may need to coordinate with the VSCode open-source maintainers to even test builds that integrate the Extension Marketplace, present only in Microsoft builds of VSCode. We would appreciate your feedback on how/whether to proceed.
Feature Request
Enhance VSCode with the basic features for extension management:
We plan to implement the extension management policy using an approach modeled on the extension management policy features in Google Chrome (and later by Mozilla, who based the extension management model of Firefox heavily on the one in Chrome), but without (at this time) its concept of a per-extension permissions model.
Deployment of the extension management policy to the managed systems would be handled out-of-band by the system's administrator, but it would be included within or referenced from the user's
settings.json
file. Right now we're not proposing to add any special controls to the settings editor UI of VSCode for editing this extension management policy. The policy will only be editable as JSON, as many other advanced features in VSCode are currently edited.We acknowledge that, for the time being, this file is within control of the user. For now, we're going to ignore that (it is tracked in #27972)
Proposed UI changes
Related Issues
70736
Client sponsor
Our client, who has agreed to participate in this discussion, is @zabicki-stripe