Perhaps this is off-topic, but I came across a rather alarming series of posts on the insecurity of VSCode extensions. I’m sure the Julia ones are fine but I wasn’t aware of just how open VSCode was, and how few checks there are in the Marketplace:
2 Likes
Has already been researched over a year ago:
1 Like
Unfortunately, this is a problem in most extensible editors. Vim, Neovim, Emacs; none of them have a permission model that restricts the capabilities of an extension, and it’s unlikely they’ll ever get one. It’s practically impossible to retrofit a capabilities/permission system into an ecosystem that didn’t have one from the start.
1 Like
I’m no expert. Do you think the new zed editor would qualify as having a permission system in it from the start? I found this issue on GitHub that at least mentions it should be possible.
Zed is still at an early stage, so it could add a permission system. However, I haven’t seen anything that says zed cares about security, and since they’re already cutting corners (like downloading unsigned executables 
), I wouldn’t count on it.
2 Likes
Yikes! 
This prompts an obvious question: is there ANY editor that cannot be hacked as described? I believe that the plain old vi may be exempt, but seems to me all powerful editors of today are wide open to bad actors of all stripes. Is that true?
1 Like
Probably. As soon as an extension is allowed to spawn a useful process, said process can do Bad Things™. Is an extension allowed to run arbitrary code in the context of your editor? Bad Things™ can happen.
Are you using a vim plugin that uses a language server in an external process? That’s a potential security issue.
3 Likes