3 ms·

Extensions often rely on third-party binaries (such as Language Servers, kubectl, ssh or even git itself), internet access (SAAS providers, pulling data or defi

by Sayrus 2y ago

Extensions often rely on third-party binaries (such as Language Servers, kubectl, ssh or even git itself), internet access (SAAS providers, pulling data or definitions, ...) and on your filesystem (SSH Config, Kubernetes config, Config folder in your home, ...). Sandboxing these extensions is not easy unless everything is configured within VSCode which is rarely the case. As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.

miohtama 2y ago
Please correct me if I am wrong but the only application (class) that currently sandboxes extensions is a web browser. So the bar is pretty high. Sandboxing does not come for a free, as it creates more complex development APIs and a performance hits.
- dumbo-octopus 2y ago
  And happily VS Code runs in the browser (vscode.dev, github.dev) if you do choose to make that security/performance trade off at some point for some reason. And with sync you can have all your UI extensions and keybindings ported over under the covers.
  - essentia0 2y ago
    not only UI extensions. for some time now extension developers can opt in to provide browser worker targeted bundles for their extensions.
    - dumbo-octopus 2y ago
      Sure, I’ve even made a handful of those myself. I contrast them with workspace extensions that run on a (possibly remote) host with full access to subprocesses/etc.
- CraigJPerry 2y ago
  Definitely. Would still be nice to have the option to opt into, for example, running as a WASM isolate - given the option of a robust sandbox, some plugins will find it desirable to migrate and gain the secure badge or however isolated plugins are marked for user identification. But There are plugins where it’s going to be too much of an uphill battle to move to that model though. I still think on balance having sandboxed plugins, however they’re implemented, would be pretty nice.
amluto 2y ago
VSCode could shove the entire extension, third party binaries included, into a sandbox, Docker-style. And “give this extension Internet access” could be an option when you install it, with the default being “no”, and a bit warning if you want to override that default. For all that the Docker ecosystem is somewhat of a mess, it seems more than adequate for this use case.
- diggan 2y ago
  > into a sandbox, Docker-style Nope, docker alone/by itself is not a sandbox, at all. Not built for that purpose, nor suitable for that purpose.
iLemming 2y ago
Extensions (in Emacs lingo we call them 'packages') are not sandboxed by design. Because unlike VSCode, you are allowed to override any, just about any part of a package's code. You can, for example, grab a command introduced in a third-party or a built-in package and override only specific parts of it without having to rewrite the entire thing. Of course, in many cases that can make your entire setup brittle - i.e., what happens when the package author decides to change some functionality that you carefully and tightly integrated into your system? At the same time, there's enormous, unmatched flexibility for making your own rules of the game - there's nothing that comes even close. You can change a function to do things that it was never initially designed for. For example, if there's a command that lets you perform GitHub search and open results in the browser, you can advise that command to change the behavior and instead of opening the results in the browser, send that data to an LLM and display it in a text buffer. You wouldn't have to rewrite the entire command; you would only have to override a specific part of it. In Vim, you'd have to rewrite the entire function. In VSCode, you'd likely have to make a separate extension. In Emacs, you wouldn't even have to save the damn thing into a file - you can write it in a scratch buffer and immediately try it out.

by Sayrus 2y ago

miohtama 2y ago

Please correct me if I am wrong but the only application (class) that currently sandboxes extensions is a web browser. So the bar is pretty high. Sandboxing does not come for a free, as it creates more complex development APIs and a performance hits.

dumbo-octopus 2y ago
And happily VS Code runs in the browser (vscode.dev, github.dev) if you do choose to make that security/performance trade off at some point for some reason. And with sync you can have all your UI extensions and keybindings ported over under the covers.
- essentia0 2y ago
  not only UI extensions. for some time now extension developers can opt in to provide browser worker targeted bundles for their extensions.
  - dumbo-octopus 2y ago
    Sure, I’ve even made a handful of those myself. I contrast them with workspace extensions that run on a (possibly remote) host with full access to subprocesses/etc.
CraigJPerry 2y ago
Definitely. Would still be nice to have the option to opt into, for example, running as a WASM isolate - given the option of a robust sandbox, some plugins will find it desirable to migrate and gain the secure badge or however isolated plugins are marked for user identification. But There are plugins where it’s going to be too much of an uphill battle to move to that model though. I still think on balance having sandboxed plugins, however they’re implemented, would be pretty nice.

amluto 2y ago

VSCode could shove the entire extension, third party binaries included, into a sandbox, Docker-style. And “give this extension Internet access” could be an option when you install it, with the default being “no”, and a bit warning if you want to override that default. For all that the Docker ecosystem is somewhat of a mess, it seems more than adequate for this use case.

diggan 2y ago
> into a sandbox, Docker-style Nope, docker alone/by itself is not a sandbox, at all. Not built for that purpose, nor suitable for that purpose.

iLemming 2y ago

Extensions (in Emacs lingo we call them 'packages') are not sandboxed by design. Because unlike VSCode, you are allowed to override any, just about any part of a package's code. You can, for example, grab a command introduced in a third-party or a built-in package and override only specific parts of it without having to rewrite the entire thing. Of course, in many cases that can make your entire setup brittle - i.e., what happens when the package author decides to change some functionality that you carefully and tightly integrated into your system? At the same time, there's enormous, unmatched flexibility for making your own rules of the game - there's nothing that comes even close. You can change a function to do things that it was never initially designed for. For example, if there's a command that lets you perform GitHub search and open results in the browser, you can advise that command to change the behavior and instead of opening the results in the browser, send that data to an LLM and display it in a text buffer. You wouldn't have to rewrite the entire command; you would only have to override a specific part of it. In Vim, you'd have to rewrite the entire function. In VSCode, you'd likely have to make a separate extension. In Emacs, you wouldn't even have to save the damn thing into a file - you can write it in a scratch buffer and immediately try it out.