6 ms·
I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.
by notnullorvoid 5mo ago
I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.
- fg137 5mo agoNot holding my breath. This issue has been open since 2018 https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116
- notnullorvoid 5mo agoYeah, the only thing that gives me hope is the optics of this happening to GitHub. Though it seems possible VS Code team could double down on the opinion that this isn't a permission/sandboxing problem, and is instead a scanning/threat detection problem.
- pamcake 5mo agoI really hope this pushes users (here: devs and maintainers) to decrease their reliance on Microsoft and especially stop outsourcing security to them. Migrate off vscode already.
- notnullorvoid 5mo ago> Migrate off vscode already. Zed is the closest thing I've found to meet my needs, and I do plan to try it. However it's dev container support looks to be lacking in some important ways so we'll see.
- TiredOfLife 5mo agoZed is even worse about arbitrarily downloading random stuff from random websites and executing it
- notnullorvoid 5mo agoHow so? Part of what seemed good about Zed was that extensions have explicit permission controls.
- TiredOfLife 5mo ago2 years ago and still nothing has changed. https://news.ycombinator.com/item?id=40902826 https://news.ycombinator.com/item?id=40902826
- no-name-here 5mo agoThat's a link to a hacker news post, which links to a reddit post, which links to https://github.com/zed-industries/zed/issues/12589 https://github.com/zed-industries/zed/issues/12589 if anyone wants to go right to the 'open' issue.
- sevenseacat 5mo agoIt will auto-install and configure any LSPs that it thinks is suitable for the code you're working on. Found that out the hard way when a new experimental Elixir LSP got added which conflicted badly with my existing installed one
- -iad 5mo agoLet me save you some hassle. I test drove Zed for a week after the v1.0 release. My projects deal exclusively in dev containers. I spent more time troubleshooting issues than actually working. Things which VS Code handles transparently, like installing the support libraries to run a chrome debug session, say. Your local SSH agent isn’t forwarded into the container, so git push doesn’t work natively. That’s after you’ve had to add your project as a safe directory in your container’s git config, because it isn’t mapped to your local git config. Things which I was disappointed and surprised were not addressed prior to v1.
- notnullorvoid 5mo agoThanks, after seeing this and others talk about it silently installing node and other tools that's enough for me to dismiss it as a viable option.
- hungryhobbit 5mo agoI won't say "you can take my VS Code from cold dead hands" or anything, but it is a very good tool, and Microsoft hasn't yet fucked it up the way they have so many other things. I guess I'd say "you take my VS Code ... willingly ... but only after M$ fucks it up and makes me not want it anymore (like they've done to everything else they acquired)".
- sieabahlpark 5mo ago[dead]
- loloquwowndueo 5mo agoVs code is a weapon, designed to fracture. It being “good” is a weapon as well. https://ghuntley.com/fracture/ https://ghuntley.com/fracture/
- kristiandupont 5mo agoThat seems like a very, very long-winded way of accusing them of "embrace, extend, extinguish"? Which is obviously not falsifiable, but just feels a bit trite at this point, IMO.
- aa-jv 5mo agoIts trite until you have to explain to your boss why your editor brought down the business.
- philipallstar 5mo agoThings feeling trite isn't a counterargument, though.
- coldtea 5mo ago>Which is obviously not falsifiable Doesn't have to be. It's been empiracally proven the case for MS time and again. How many times do you need it to happen because you treat it as the default?
- 5mo ago
- ajross 5mo ago> Migrate off vscode already. It's not the IDE, though. Any extensible, customizable display editor can be coerced into behaving badly by installing external code. Even this one: https://www.gnu.org/software/emacs/emacs-paper.html https://www.gnu.org/software/emacs/emacs-paper.html The root(-ish) cause here is the ease of publishing and installing extension code, and in particular the fact that there's no independent validation/verification step between the upstream author and armageddon. And upstream authors aren't set up with the needed precautions themselves, they're just hackers. Basically if you phish Just One Account with write access to an extension you wan pwn everyone who's running it.
- skydhash 5mo ago> Any extensible, customizable display editor can be coerced into behaving badly by installing external code. But I think only VS Code (And Jetbrain's ones) is so pushy about installing extensions. With Emacs, you actually have to go find them and install it. And then you actually have to make a conscious effort to update them. Same with vim. I'm pretty sure VS Code enable auto updates. And I would guess the people publishing Emacs's package and Vim's plugin are way more conscious about security.
- prmoustache 5mo agoI like neovim but I am under no illusion that plugins developers would be more conscious about security. The thing is there is no marketplace so it is less easy to make your plugin suddently advertised and installed by thousands of people without having a killer feature.
- skydhash 5mo agoTo hijack a vim plugin/emacs package, you would have to take over the repo. Or take over elpa/melpa (for emacs) or vim awesome (to redirect users to your malicious repo). Both are way tricker than the exploitation tactics used on JS based projects.
- Gigachad 5mo agoThe problem is not VS code itself. It's the fact extensions can access things outside of the editor. As far as I am aware, no editor sandboxes extensions.
- stephenr 5mo agoPart of the problem is that people are adding a metric fuck ton of extensions onto a text editor trying to make it into an IDE. If you start with an IDE first you likely need far fewer extensions.
- aa-jv 5mo agoHow about just don't become dependent on an IDE and don't use technologies which require that dependency...
- stephenr 5mo agoGood point. Any editor is a needless dependency. True developers just scream at the universe and it responds with cosmic radiation that flips the correct bits to form the binary code they intended.
- tmtvl 5mo agoAh, good old 'M-x scream-into-void'. My most-used Emacs feature after 'M-x butterfly'.
- aa-jv 5mo agoTrue developers don't leak the keys to their sources just because they need convenience-features from a "free IDE with tons of sexy bells and whistles" .. Features that would, incidentally, be obviated by making just a bit of a better effort to be better managers of the filesystem and ones' source code - and thus: become more competent developers. There is a limit to the positive impact of convenience features in any tools, not just IDE's. We are seeing that limit being broached with every exfiltration of repo keys attributed to VSCodes' crap anti-user architecture ... You'll scream at the universe when it happens to you.
- spudlyo 5mo agoEmacs has been a viable option for going on a half century now. The GNU Emacs 31 branch[0] was cut recently and is barreling towards a new release. It might be time to give it another look. I'm not saying its package ecosystem isn't vulnerable to these kind of attacks, it is, but it's at least developed by folks with very different goals and ambitions than Microsoft. [0]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS
- simiones 5mo agoThere's nothing really special about VSCode here, except that it's really popular. You could just as easily attack Emacs or Vim or Sublime or [...] users by distributing a malicious extension.
- skydhash 5mo agoYou can’t attack them that easily because of the different publication method. Emacs, Vim, and Sublime have a pull model (like linux distros), not a push model. Meaning you add your repos to the package hub, you do not upload an archive to them. The Hub will pull in you changes (or the plugin manager will do so). The only way in is to take over the repo itself.
- simiones 5mo agoNot sure how Vim and Sublime work, but for Emacs, publishing to MELPA is absolutely a push process, where you open a PR to MELPA's repo with a recipe for your new package; and, once it's accepted, every commit to your repo results in a new package build on MELPA's servers that Emacs users will get when they update / install the new plugin.
- skydhash 5mo agoIt’s not. The developer never build a package and then upload on melpa. Melpa will fetch the needed files and build the package. It’s not truly secure, but an attacker would need to publish a new commit and wait for quite some time for people to update. Another thing is that some packages are old. Seeing an update out of the blue would be very strange. And for packages that are updated more often, I guess the maintainer would be quite surprised to see a new commit they’ve not approved of.
- simiones 5mo agoMy point is, if I want to create a malicious Emacs plugin, I can do the following: 1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point. 2. Wait for people to pick up this new extension, while it's still benign. 3. Push the malicious version to my own GitHub repo. MELPA will automatically pick it up, build it, and package it. 4. Anyone updating their Emacs packages from MELPA or installing it from MELPA will pick up this malicious version. Now, this does require that the malicious code is visible on the extension's GitHub page; I'm not sure if this would be true on VSCode as well.
- panchtatvam 5mo agoSure. Microsoft will spin up a "SuPeR AI AgEnT" that will "fix" the issue. As an added benefit, it will officially promote Edge and Win 11 ( or K2 )
- 0xpgm 5mo agoIt is said that these agents make one 100x more productive by some accounts. Microsoft is big on AI agents. If these claims were true, why don't they point the agents at the numerous stability and security issues they have across their various platforms?
- crabbone 5mo agoBefore I say anything: I don't use VSCode and have no intention of doing so. Most of my experience is gained vicariously, through working with or helping someone else who does. I use Emacs for my day-to-day stuff. I don't think Emacs extensions are more secure by design. Pretty sure that, if I wanted to, I could craft an extension that does bad things. I'm not sure how hard it would've been to sneak it past MELPA or (is there really anything else people are using these days? Used to be Marmalade, but I think it's gone), but, it's people, and people make mistakes, so, there's some % chance that a bad extension can be inserted there. Such security problems happen to a lesser extent (if at all?) in the Emacs world because of the size of the user base. It's simply impractical to target a small community, as it's always a numbers game. Very unwillingly, and with a lot of contempt, I use Android, where this "explicit permissions system" you speak of exists. There are many reasons to hate Android, and the "explicit permissions system" is a prominent member in that collective. Companies like MS, Google etc. always default to this way of solving their security issues: by restricting their users from doing useful things. They model their users as a herd of brainless lemmings who must be herded with an iron fist in order for them not to plunge to their deaths (yes, I know, real-life lemmings don't do that, but we all know the metaphor). And this tactics is so common that the MS-lemmings learn to yearn for it. The solution I want to see to this and similar problems is two-fold: 1. Users learn to use their tools. 2. Users learn to treat important information on their computers in a more defensive way, if they open the door for outside, potentially bad, software providers. This is, of course, a pie in the sky sort of wish... But, imagine it was achievable, wouldn't the world be a better place? Now, I believe it's possible to approach these goals gradually, and it would still be better than a system imposed by the software provider that prevents users from doing useful things. For example, Emacs has a mechanism to prompt users when attempting to use a particular functionality. Some of it is because the functionality can be surprising for the novice, some of it is because it could be dangerous from the security standpoint. So, in principle, VSCode could do that too. Eg. a user would have to interactively grant its extensions permissions to call whatever functionality within the editor, while some "dangerous" functionality would have to be removed from the JavaScript runtime available to VSCode and only made available in this interactive way (eg. when JavaScript code in VSCode extensions wants to call exec() or similar, it would have to call an overloaded exec() provided by VSCode, that would inform the user that such-and-such extension wishes to run such-and-such command, and that it needs their permission to do it).
- deely3 5mo agoOh, you mean like only extensions approved by MS can be published? Similarly to Google, Apple, Mozilla and others?
- notnullorvoid 5mo agoNo I don't mean like that. Explicit permissions control what the extension can do, similar to websites needing explicit permission to access a users camera. An example is a theme extension with permission to change the theme, but having neither permission to run scripts/executables, nor dynamically access the filesystem. There's no connection to authoritative approval, other than making ecosystems without or without that kind of strict approval safer.