I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.
Migrate off vscode already.
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)".
Not for lack of trying, the amount of CoPilot cruft bundled with the core IDE is growing quarterly.
Every updates release notes is like 90% “now with more copilot plz use it.”
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?
I beg to differ. Have you inspected its network traffic?
Yes, very definitely.
Can you?
And are you a vscode original? or came from vim/emacs?
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
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.
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.
If you start with an IDE first you likely need far fewer extensions.
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.
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.
I can assure you I am not.
The sarcasm was because this suggestion is ridiculous IMO. It's like saying "Tesla refuses to use state-of-the-art LIDAR for their attempts at an autonomous vehicle, therefore I shall only travel in vehicles that have both a driver and a conductor, and are propelled by beasts!".
VSCode being a turd isn't a reason not to use an IDE. It's a reason to use an actual IDE, rather than a glorified text editor, with the aforementioned millions of shonky plugins trying to recreate IDE levels of functionality.
But here's the point: All IDE's eventually become liabilities as they attempt to become an operating system.
Better to just use a text editor, learn to use the build tools, navigate the filesystem with tools that don't have plugins sourced from external sources, etc.
Of course, if your language and execution environment of choice don't allow this, thats another thing entirely. I know you can't do proper javascript development without an IDE - and that's the issue, actually. You shouldn't need a special editor with bells and whistles to do development, and on that point I agree with you entirely.
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.
Part of what seemed good about Zed was that extensions have explicit permission controls.
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.
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.
Good luck on that. Check the most popular packages and they all belong to fairly well known people in the community. If it’s something small, people usually just copy the relevant bit to their config. And rarely do huge systems pick up users without active advocacy (helm, ivy, vertico, company, magit, consult, hyperbole, emms, org-mode,…) which means collaboration and plenty of people looking at upstream.
But the issue is not new users picking up unconfirmed packages. It’s about active employees getting compromised by extensions they trusted. As the nature of packages update is opaque and the default settings leave you vulnerable.
If you go on magit’s page on melpa, you get the commit id used for the build and if you wanted too, you could diff the files with upstream. Everything is transparent. Meanwhile what you got on marketplace is whatever is pushed by a token.
And another nice thing about packaging system like emacs is that they rely on peer dependencies instead of pulling their own from the internet. Which is nice, because when a bug is patched, you update that single dependency and you’re done. No need to update every package that depends on it.
Very, very few people, even in tech circles, check the sources of all of their dependencies. Sure, compromising magit's sources will be hard - but you don't need to compromise magit. Just compromise one of magit's dependencies and watch the malware spread.
Edit: in fact, you don't even need to compromise Magit's dependencies. Since the developers of Magit probably use Emacs themselves, you can probably just compromise some small Emacs package that happens to be used by someone on the Magit team, get access to their repo from there, and then you actually may be able to compromise Magit itself (depending on how strict their code review etc rules are).
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
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?
There's no connection to authoritative approval, other than making ecosystems without or without that kind of strict approval safer.
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).
That Just Won't Happen. Especially not in a corporate/government setting. In my experience, it's rare for people to actually want to improve how they work without there being external pressure. Workflows once learned become very, very hard to unlearn and it's already a massive issue when you are responsible for a piece of business software that's used by a hundred users - I once was on a team responsible for the software used by tens of thousands of people. Major changes always, always had to be accompanied by training material and the time for that training had to be budgeted as well.
A large part of the issue is cultural/financial realities. People are already overloaded with work as penny pinchers think it's wise to keep people at 100% utilization leaving no gaps for anything - they know that if they become more efficient, their workload will not go down, their bosses will just dump more things on their table. And people don't want to train for their job if they're not paid for it, as well.
Please, read what you quoted to the end. The answer is right there.
Anyways. Here are examples to the contrary: cars and driving. Somehow, collectively, we realized that driving requires learning the tools to a minimal proficiency level. This doesn't prevent anyone from driving a car w/o a license (a document certifying one's learned the tools), but it puts the blame for a certain category of accidents on the driver, thus making it unnecessary to demand absolute road safety from car manufacturers.
What if we treated computers more like cars? Perhaps, in a situation like this, products s.a. VSCode wouldn't even exist in the same way how there aren't cars that don't come equipped with safety belts?
Right now, parent suggests, metaphorically, to equip cars with a system that plans the route in advance, has a required number of passengers for each planned trip and won't even open the doors unless the car reaches its destination. This is what "explicit permission system" is to a computer user lucky enough to have avoided most of the MS / Google / Apple and Co products.