Hacker News Reader

Comment by getpokedagain | Hacker News Reader

Not trolling here but these things are by design cesspools ready for compromise. Any fully open ecosystem where contributions are not strictly reviewed is open to this problem. If you don't like it, don't use editor extensions and use a well audited editor.

If you want to use extensions or node packages or pypi packages without doing a detailed review you're accumulating technical debt. You're assuming a risk in order to ship rapidly. You can either pay that down at some point under control, or bear the interest when it comes due.

View on HN

Extensions never had to be given unsandboxed access to everything. That's a choice that they actively made.

I mean I don't think some sort of "access control" within the editor is going to really address this. People edit sensitive text in their code editor and no matter what that is going to be available to most useful extensions. Even if you don't lose a credential or get some arbitrary script running to mine crypto on your machine you could have an extension function as a key logger and exfil code you really think is valuable.

It would have restrained the access here. The extension would have only had access to the repos opened by this individual rather than an api key that gave access to 3,800 repos.

They probably should have some permission system where the default extension is only able to operate within the repos open at the time and has no internet access. Then you can grant internet access for the ones which genuinely need it.

The majority of VS code plugins are just syntax highlighers and linters which don't need any dangerous permissions.

Most of these problems could be solved with something like wasm/wasi where you can limit access to web, disk, etc... WASI is made to run code you don't trust, you could even limit compute third party is using so they can't mine crypto (I think it's called fuel limit). Ideally we would have whole IDE run in this kind of environment where we can explicitly say what it can and can't do.

its easy to complain, words are cheap. fork it and change it if you don't like it

It's easy to wave a magic wand and have one developer do better than a corporation of tens of thousands. There is a reason I don't use Microsoft products: I can't do it myself and do won't do it for me.

There is no editor that sandboxes extensions as described.

Emacs, vim/nvim, intellij, etc… pretty much all vulnerable to such an attack

Reality is most devs wouldn’t be satisfied with the limitations proper sandboxing would create.

Then you lose access to the VSCode marketplace which kind of defeats the purpose.

Reply on news.ycombinator.com