As called out elsewhere, workspace trust is literally the protection here which is being circumvented. You're warned when you open a folder whether you trust the origin/authors with pretty strong wording. Sure you may find this annoying, but it's literally a security warning in a giant modal that forces you to chose.
Even if automatic tasks were disabled by default, you'd still be vulnerable if you trust the workspace. VS Code is an IDE and the core and extensions can execute code based on files within the folder in order to provide rich features like autocomplete, compilation, run tests, agentic coding, etc.
Before workspace trust existed, we started noticing many extensions and core features having their own version of workspace trust warnings popping up. Workspace trust unified this into a single in your face experience. It's perfectly fine to not trust the folder, you'll just enter restricted mode that will protect you and certain things will be degraded like language servers may not run, you don't be able to debug (executes code in vscode/launch.json), etc.
Ultimately we're shipping developer tool that can do powerful things like automating project compilation or dependency install when you open a folder. This attack vector capitalizes on neglectful developers that ignore a scary looking security warning. It certainly happens in practice, but workspace trust is pretty critical to the trust model of VS Code and is also an important part to improve the UX around it as we annoy you a _single_ time when you open the folder, not several times from various components using a JIT notification approach. I recall many discussions happening around the exact wording of the warning, it's a difficult to communicate concept in the small amount of words that it needs to use.
My recommendation is to use the check box to trust the parent or configure trusted folders. I personally have all my safe git clones in a dev/ folder which I configured to trust, but I also have a playground/ folder where I put random projects that I don't know much about and decide at the time I open something.
I suspect that you're relying too heavily on the user here. Even for myself, a very experienced developer, I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment. I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it". Expecting us to surface from our flow, think about the risks and make an informed decision might on the surface seem like a fair expectation, but in the real world, I don't think it's going to happen.
Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state. But now you're relying on people to have known about the question beforehand, and have this strategy worked out ahead of time.
If you're going to rely on this so heavily, maybe you should make that strategy more official, and surface it to users ahead of time - maybe in some kind of security configuration wizard or something. Relying on them to interrupt flow and work it out is asking too much when it's a security question that doesn't have obvious implications.
> I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment
Maybe I'm too close to it, but the first sentence gives a very clear outline of the risk to me; Trusting this folder means code within it may be executed automatically.
> I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it".
I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
> Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state.
You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
> Trusting this folder means code within it may be executed automatically.
But as you point out elsewhere, what constitutes code is very context dependent. And the user isn't necessarily going to be sufficiently expert on how Code interacts with the environment to evaluate that context.
> I'm curious what would stop you from opening it in restricted mode?
Even after years of using Code, I don't know the precise definition of "restricted mode". Maybe I ought to, but learning that isn't at the top of my list of priorities.
> You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
NO! Not even close! And maybe this is at the heart of why we're not understanding each other.
My goal is not to run an editor and change some characters, not at all. It's so far down the stack that I'm scarcely aware of it at all, consciously. My goal is to, e.g., find and fix the bug that the Product Manager is threatening to kill me over. In order to do that I'm opening log files in weird locations (because they were set up by some junior teammate or something), and then opening some code I've never seen before because it's legacy stuff 5 years old that nobody has looked at since; I don't even have a full picture of all languages and technologies that might be in use in this folder. But I do know for sure that I need to be able to make what edits may turn out to be necessary half an hour from now once I've skimmed over the contents of this file and its siblings, so I can't predict for sure whether whatever the heck "restricted mode" will do to me will interfere with those edits.
I'm pretty sure that the above paragraph represents exactly what's going on in the user's mind for a typical usage of Code.
Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"?
In light of this vulnerability, the team may want to revisit some of these assumptions made.
I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this workspace?' and hit the big blue "Yes" button to quickly just get to work.
With AI and agents, there are now a lot of non-dev "casual" users using VS code because they saw something on a Youtube video too that have no clue what dangers they could face just by opening a new project.
Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).
Didn't mean to come off that way, I know a lot of the decisions that were made. One thing I've got from this is we should probably open `/tmp/`, `C:\`, ~/`, etc. in restricted mode without asking the user. But a lot of the solutions proposed like opening everything in restricted mode I highly doubt would ever happen as it would further confusion, be a big change to UX and so on.
With AI the warning needs to appear somewhere, the user would ignore it when opening the folder, or ignore the warning when engaging with agent mode.
> Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).
I’m not sure this is possible or non-misleading at the time of granting trust because adding or updating extensions, or changing any content in the folder after trust is granted, can change what will be executed.
For what it's worth, I absolutely agree with the comments saying the warning doesn't clearly communicate the risks. I too had no idea opening a directory in VS Code (that contains a tasks.json file) could cause some code to execute. I understood the risk of extensions but I think that's different, right? i.e. opening a trusted project doesn't automatically install extensions when there's an extensions.json (don't quote me on that, unless that's correct)
To give some perspective: VS Code isn't my primary IDE, it's more like my browsing IDE. I use it to skim a repo or make minor edits, without waiting for IntelliJ to index the world and initialize an obscene number of plugins I apparently have installed by default. Think—fixing a broken build. If I'm only tweaking or reinstalling dependencies because the package-lock file got corrupted and that's totally not something that happened this week, I don't need all the bells and whistles. Actually I want less because restarting the TypeScript service multiple times is painful, even on a high end Mac.
Anyway enough about IntelliJ. This post has some good discussions and I sincerely hope that you (well, and Microsoft) take this feedback seriously and do something about it. I imagine that's hard, as opposed to say <improving some metric collected by telemetry and fed into a dashboard somewhere>, but this is what matters. Remember what Steve Ballmer said about UAC? I don't know if he said anything, but if it didn't work then it's not going to work now.
> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
Have you tried it? It breaks a lot of things that I would not have expected from the dialog. It’s basically regressing to a slightly more advanced notepad.exe with better grepping facilities in some combinations of syntax and plugins.
> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
loss of syntax highlighting and to a lesser extent the neovim plugin. maybe having some kind of more granular permission system or a whitelist is the answer here.
opening a folder in vscode shouldn't be dangerous.
> opening a folder in vscode shouldn't be dangerous.
You're not "opening a folder" though, you're opening a codebase in an IDE, with all the integrations and automations that implies, including running code.
As a developer it's important to understand the context in which you're operating.
If you just want to "open a folder" and browse the contents, that's literally what Restricted mode is for. What you're asking to do is already there.
I've been using VS Code for many years and I try pretty hard to be a security aware dev.
I checkout all code projects into ~/projects. I don't recall ever seeing a trust/restricted dialogue box. But, I'm guessing, at some point in the distant past, I whitelisted that folder and everything under it.
I've only just now, reading through this thread, realized how problematic that is. :o/
Syntax highlighting should work if the highlighting is provided by a textmate grammar, it will not work if it's semantic highlighting provided by an extension and that extension requires workspace trust. If it's possible to highlight without executing code, that sounds like an extension issue for whatever language it is. I believe extensions are able to declare whether they should activate without workspace trust and also to query the workspace trust state at runtime.
The funny part is that everyone expects you to make an informed decision about your security, without even providing any data to make that decision.
A better strategy would be:
- (seccomp) sandbox by default
- dry run, observe accessed files and remember them
- display dialog, saying: hey this plugin accesses your profile folder with the passwords.kdbx in it? You wanna allow it?
In an optimum world this would be provided by the operating system, which should have a better trust model for executing programs that are essentially from untrustable sources. The days where you exactly know what kind of programs are stored in your folders are long gone, but for whatever reason no operating system has adapted to that.
And before anyone says the tech isn't there yet: It is, actually, it's called eBPF and XDP.
You also get problems with overwarning causing warning fatigue. Home Assistant uses VS Code as its editor (or at least the thing you use to replace the built-in equivalent of Windows Notepad) and every single time I want to edit a YAML config file I first have to swat away two or three warnings about how dangerous it is to edit the file that I created that's stored on the local filesystem. So my automatic reaction to the warnings is "Go away [click] Go away [click] Go away [click], fecking Microsoft".
How is this any different than anything else devs do? Devs use `curl some-url | sh`. Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.
Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.
You allow developers to download and run arbitrary packages? Where I came from, that went out years ago. We keep "shrinkwrap" servers providing blessed versions of libraries. To test new versions, and to evaluate new packages, there's a highly-locked-down lab environment.
Sorry, but this reply is just ridiculous. There's more to being a developer than just writing a bunch of code in a flow state. And it's silly to claim you're so deep in "flow" that you can't be bothered to read and understand a security popup.
If that's how you work, then you're part of the problem.
Yes. If you "can't" read the security popup that very clearly tells you that this is a risky action and you should only do it if you trust the repo, then it's either a reading comprehension issue, and you should take remedial classes - or you're intentionally ignoring it, and so deeply antisocial and averse to working with other people.
Both of those things are extremely bad in any work environment and I would never hire someone displaying either of those traits.
I think it would be better to defer the Workspace trust popup and immediately open in restricted mode; maybe add an icon for it in the bottom info bar & have certain actions notify the user that they'd have to opt in before they'd work.
Because right now you are triggering the cookie banner reflex where a user just instinctively dismisses any warnings, because they want to get on with their work / prevent having their flow state broken.
There should also probably be some more context in the warning text on what a malicious repo could do, because clearly people don't understand why are you are asking if you trust the authors.
And while you're at it, maybe add some "virus scanner" that can read through the repo and flag malicious looking tasks & scripts to warn the user. This would be "AI" based so surely someone could even get a job promotion out of this for leading the initiative :)
Some JIT notification to enable it and/or a status bar/banner was considered, but ultimately this was chosen to improve the user experience. Instead of opening a folder, having it restricted and editing code being broken until you click some item in the status bar, it's asked up front.
It was a long time ago this was added (maybe 5 years?), but I think the reasoning there was that since our code competency is editing code, opening it should make that work well. The expectation is that most users should trust almost all their windows, it's an edge case for most developers to open and browse unfamiliar codebases that could contain such attacks. It also affects not just code editing but things like workspace settings so the editor could work radically different when you trust it.
You make a good point about the cookie banner reflex, but you don't need to use accept all on those either.
IMO this is a mistake, for basically the same reason you justify it with. Since most people just want the code to work, and the chances of any specific repo being malicious is low, especially when a lot of the repos you work with are trusted or semi-trusted, it easily becomes a learned behavior to just auto accept this.
Trust in code operates on a spectrum, not a binary. Different code bases have vastly different threat profiles, and this approach does close to nothing to accomodate for that.
In addition, code bases change over time, and full auditing is near impossible. Even if you manually audit the code, most code is constantly changing. You can pull an update from git, and the audited repo you trusted can be no longer trustworthy.
An up front binary and persistent, trust or don't trust model isn't a particularly good match match for either user behavior or the potential threats most users will face.
So why not allow for enabling this behavior as a configuration option?
A big fat banner for most users (i.e. by default) and the few edge cases get the status bar entry after they asked for it.
I find this reply concerning.
If its THE security feature, then why is "Trust" a glowing bright blue button in a popup that pop up at the startup forcing a decision. That makes no sense at all. Why not a banner with the option to enable those features when needed like Office tools have.
Also the two buttons have the subtexts of either "Browse folder in restricted mode" or "Trust folder and enable all features", that is quite steering and sounds almost like you cannot even edit code in the restricted mode.
"If you don't trust the authors of these files, we recommend to continue in restricted mode" also doesn't sound that criticial, does it?
>You're warned when you open a folder whether you trust the origin/authors with pretty strong wording.
I can see the exact message you're referring to in the linked article. It says "Code provides features that *may* automatically execute files in this folder." It keeps things ambiguous and comes off as one of the hundreds of legal CYA pop-ups that you see throughout your day. Its not clear that "Yes, I trust the authors" means "Go ahead and start executing shell scripts". Its also not clear what exactly the difference is between the two choices regarding how usable the IDE is if you say no.
"May" is the most correct word though, it's not guaranteed and VS Code (core) doesn't actually know if things will execute or not as a result of this due to extensions also depending on the feature. Running the "Manage Workspace Trust" command which is mentioned in the [docs being linked][0] to goes into more detail about what exactly is blocked, but we determined this is probably too much information and instead tried to distill it to simplify the decision. That single short sentence is essentially what workspace trust protects you from.
My hope has always been, but I know there are plenty of people that don't do this, is to think "huh, that sounds scary, maybe I should not trust it or understand more", not blinding say they trust.
Dunno how to break it to you but most of the people using AI the most, they are not very good at computers.
I think with AI we quickly progress to level where it needs to essentially run in nice lil isolated sandbox with underlying project (and definitely everything else around it) being entirely read only (in form on overlay FS or some similar solution), let it work in the sandbox and then have user only accept the result at end of the session in form of a separate process that applies the AI changes as set of commits (NOT commiting direct file changes back as then malicious code could say mess stuff up in .git dir like adding hooks). That way at very worst you're some commit reverts out in main repo.
AI certainly made everything in this area more complicated. I 100% agree about sandboxing and we have people investing in this right now, there's an early opt-in version we just landed recently in Insiders.
Meet the new Microsoft - same as the old one. This is the same reasoning that led to a decade of mindnumbingly obvious exploits against Internet Explorer. You've got to create secure defaults. You have to ask whether your users really want or need some convenience that comes at the expense of an increased attack surface.
It's intentionally prominent as you're in a potentially very degraded experience. You can just click the x to hide it which is remembered the next time you open the folder. Not having this banner be really obvious would lead to frustrated users who accidentally/unknowingly ended up in this state and silly bug reports wasting everyone's time about language services and the like not working.
First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.
The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:
1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.
2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about:
"presentation": {
"reveal": "never",
"echo": false,
"focus": false,
"close": true,
"panel": "dedicated",
"showReuseMessage": false}
3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.
Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).
My main hesitation here was that really it's just a false sense of security though. Tasks is just one of the things this enables, and in the core codebase we are unable to determine what exactly it enables as extensions could do all sorts of things. At a certain point, it's really on the user to not dismiss the giant modal security warning that describes the core risk in the first sentence and say they trust things they don't actually trust.
I've also created these follow ups based on this thread:
Oh wow that's the first time I've heard about those tasks. I would never consent to that and that they are enabled by default and shipped in the .vscode folder where most people probably nevereven would have thought about looking for malicious things that's kind of insane.
would it possible to show to alert only when there are potentials threats instead of every time a folder is open? Like showing a big red alert when opening a folder for the first time with a ".vscode" folder in it?
It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services. How could this threat detection possibly be complete? In this new LLM-assisted world a malicious repository could be as innocuous as a plain text prompt injection attack hidden in a markdown file, or some random command/script that seems like it could be legitimate. There are other mitigations in place and in progress to help with the LLM issue, but it's a hard problem.
This demonstrates the actual real-world problem, though. You're saying "this is a complex problem so I'm going to punt and depend on the user to resolve it". But in real life, the user doesn't even know as much as you do about how Code and its plugins interact with their environment. Knowledgewise, most users are not in a good position to evaluate the dangers. And even those who could understand the implications are concentrating on their goal of the moment and won't be thinking deeply about it.
You're relying the wrong people, and at the wrong time, for this to be very effective.
> It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services.
Which code? Its own Code (which the user already trusts anyway), or code from the workspace (automatically)? My expectation with a language-server is that it never code from the workspace in a way which could result in a side effect outside the server gaining understanding about the code. So this makes little sense?
Your expectation is wrong in this case for almost all languages. The design of Pylance (as is sorta forced by Python itself) chooses to execute Python to discover things like the Python version, and the Python startup process can run arbitrary code through mechanisms like sitecustomize.py or having a Python interpreter checked into the repo itself. To my knowledge, Go is one of the few ecosystems that treats it as a security failure to execute user-supplied code during analysis tasks, many languages have macros or dynamic features that basically require executing some amount of the code being analyzed.
Installing dependencies on folder open is a massive misfeature. I understand that you can't do anything about extensions that also do it but I really hope that you guys see how bad an idea that is for the core editor. "Do I trust the authors of this workspace" is a fundamentally different question than "can I run this code just by looking at it"
> It's perfectly fine to not trust the folder, you'll just enter restricted mode that will protect you and certain things will be degraded like language servers may not run, you don't be able to debug (executes code in vscode/launch.json), etc.
This is the main problem with that dialog: It’s completely unclear to me, as a user, what will and will not happen if I trust a workspace.
I treat the selection as meaning that I’m going to have nothing more than a basic text editor if I don’t trust the workspace. That’s fine for some situations, but eventually I want to do something with the code. Then my only options are to trust everything and open the possibility of something (?) bad happening, or not do any work at all. There’s no visibility into what’s happening, no indication of what might happen, just a vague warning that I’m now on my own with no guardrails or visibility. Good luck.
My first reaction has been: when we install some node modules, import them and eventually run them, we do grant local execution permissions to whatever the authors of those modules coded in their scripts, right? More or less every language already suffer from the same problem. Who vets the code inside a Ruby gem, a Python package, etc? Add your favorite language.
However I did not know about tasks.json (I don't use VSC) and when I googled it I found the example at https://code.visualstudio.com/api/extension-guides/task-prov... and that is about running rake (Ruby.) So this is a little worse than installing malicious packages: the trigger is opening a malicious repository from the editor. Is this a common practice? If it is, it means two things: 1) the developer did not take an explicit choice of installing and running code, so even the possibility of an attack is unexpected and 2) it affects users of any language, even the ones that have secured package installation or have no installation of packages from remote.
You get asked if you trust the folder you’re opening every single time you open a new folder in VsCode. Everyone probably always just says yes but it’s not like it doesn’t tell you that opening untrusted folders is dangerous.
Until this post it wasn't clear to me that just opening and trusting a directory can cause code to be run without taking any other explicit actions that seem like they might involve running code, like running tests. My bad, but still!
mjdv : > it wasn't clear to me that just opening and trusting a directory
andy_ppp : >obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.
Understandably, there's a disconnect in the mental model of what "opening a folder" can mean in VSCode.
In 99% of other software, folders and directories are purely navigation and/or organization and then you must go the extra step of clicking on a particular file (e.g. ".exe", ".py", ".sh") to do something dangerous.
Furthermore, in classic Visual Studio, solutions+projects are files such as ".sln" and ".vcsproj" or a "CMakeLists.txt" file.
In contrast, VSCode projects can be the folders. Folders are not just purely navigation. So "VSCode opening a folder" can act like "MS Excel opening a .xlsm file" that might have a (dangerous) macro in it. Inside the VSCode folder may have a "tasks.json" with dangerous commands in it.
Once the mental model groks the idea that a "folder" can have a special semantic meaning of "project+tasks" in VSCode, the warning messages saying "Do you trust this folder?" make more sense.
VSCode uses "folders" instead of a top-level "file" as a semantic unit because it's more flexible for multiple languages.
To re-emphasize, Windows File Explorer or macOS Finder "opening a folder" do not run "tasks.json" so it is not the same behavior as VSCode opening a folder.
Oh man! Microsoft was the #1 company with this problem for over 25 years and they still do it?
Word and Excel “MACROS” used to be THE main vector for kiddie viruses. Come on M$ … billions of dollars and you’re still loading up non-interactive code execution in all your documents that people expect to be POD (Plain Old Data)?
Is it so much to ask for your software to AT LEAST warn peole when it’s about to take a destructive action, and keep asking until the user allows that class of thing non-interactivlely ONLY FOR THAT SIGNED SOFTWARE?
VS Code does exactly that, warns before loading this non-interactive code. It warns you loudly, with an ugly modal dialog, on opening a new to it folder and suggests Restricted Mode. A lot of the arguments here relate to:
1) This loud warning is easy to ignore, despite how loud it is
2) This loud warning is easy to disable, which many desire to do because it is very loud
3) This loud warning is easy to build bad habits (instead of marking safe parent folders, continually clicking Allow and training yourself to only click Allow)
4) Restricted Mode sounds "too restricted" to be useful (though it isn't too restrictive and is very useful)
5) Restricted Mode is also loud to remind you that you are in it, so many users think it is too loud and never want to be in it (despite it being very useful)
Maybe I'm confused at what you mean, but I don't think there's a huge difference. Loading code is a dangerous action. VS Code is doing exactly what the video is talking about: it gives you a big popup window before doing a dangerous action (that could violate your privacy, that could be malware, that could do things you don't expect).
We want to load code in Turing complete languages. We want complex build tools and test harnesses to load "just so", and those too are generally Turing complete and configured and written in Turing complete languages. Parsing code in a Turing complete language takes another Turing complete language, generally. (Most languages are self-hosted so parsing the code is an action in that same language.)
One of the most dangerous actions we know of is an ancient and inescapable "bug" in all Turing complete work: the Halting Problem. We cannot mathematically prove any program will complete nor when it will complete, without running it and waiting for it to complete, if it completes. Infinite loops are both the power granted to us by our tools and the potential downfall of them all, our responsibility to deal with them is in our hands and math can't help us enough.
Loading code is a dangerous action. VS Code is doing the right thing in how it is handling it. It's not the best user experience and clearly not enough users understand the dangers inherent in "do you really want to run all your extensions in this folder?" in precisely the same way that people better understand "Do you want this application to have access to your precise location?" is a threat (that apps do take advantage; in both cases).
Some instructions are benign, eg to add two numbers or even divide by zero
Other instructions call APIs of the OS
It is at these times that the user should be prompted interactively whether they want the action to be done, with full details of what the scope is, and keep asking every time until the user checks a box that says “continue allowing this action on this scope to THIS program”.
I think I see what you are asking: why isn't it more granular?
In VS Code the granular options exist, too. Restricted Mode is just a pseudo-profile with (almost) no Extensions loaded and a couple other settings disabled. You can use the VS Code profiles and workspace controls to set many other granular in-between states.
I think where the fundamental disagreement I have with your perspective lies, and it is sort of the decades-long "lesson of Windows and Office" (which I'll circle back to) and also one of the deepest, oldest theoretical concerns of Computer Science, is that there is unfortunately no such thing as "benign code". The Halting Problem and its corollary the "Zero-Day Sandbox Exploit in the Universal Turing Machine" suggest that mathematically we have no real tools to determine what is actually benign versus what looks benign.
If you don't like the math theory side of that argument, then we can absolutely discuss the practical, too. We can start with the example you have given that even divide by zero can be benign. That's a pretty good example. We've designed computers so they don't halt and catch fire on a divide by zero, sure, but to do that we have things like stateful error registers and even processor interrupts to jump immediately to different code when a divide by zero happens. Other code could be relying on those error registers as well and may get to its own unexpected state. Interrupts and jumps can be taken advantage of to run code the original program never expected to run.
Little processor-level details like that add up and you get giant messes like SPECTRE/MELTDOWN.
That's also just one low level place to inject malware, you can do it in any programming language anywhere in the stack. This is where VS Code is especially in such an unenviable position because it wants to be a development environment for all possible programming languages so has just about no idea what the full breadth of the stack of programming languages you've configured to want to run in the Extensions that you've installed and the CLI tasks it can automate. VS Code isn't your Operating System (it is not yet trying to be that much like Emacs), it doesn't sandbox your Extensions, it doesn't limit what APIs the CLI build tools you have installed can run.
There are practical exploits of this directly in the article here. More can be found with easy searching. Granularity only helps so much. A big general, loud warning isn't the best experience, but its the closest to the safest option available to VS Code (not just because it isn't your OS, and also OSes are omniscient).
The safest option for VS Code really is "Don't autostart anything, it might be dangerous". Just as Windows has had to stop autorunning JScript and VBScript (once considered "benign"). Just as Windows has had to stop autorunning AUTOEXEC.INI instructions when a CD or USB disk is inserted (once considered "benign"). Just as Office has had to stop running VBA macros on startup (once considered benign). I wish VS Code took a couple more steps towards the Excel experience ("Protected Mode" sounds kinder than "Restricted Mode", it's a subtle difference, but subtle differences matter; fewer flow-interrupting modals and more "quietly default to Protected Mode"), but the general principle here isn't in question in my mind.
But going back to this is also deeply and disturbingly tied back to some of the oldest theories and questions of Computer Science, it also seems useful to remind everyone that if you want to feel truly paranoid, the only safe way to use a computer is to never use a computer. We don't know how to differentiate benign code from dangerous code, we likely never will. Not your OS, not your code editor, not even your abstract Universal Turing Machine you are running with pencil and paper. Unless we find some sort of left-field solution to the Halting Problem, we're kind of stuck with "Computers are inherently dangerous, proceed with caution".
I don't like the way it is handled. Imagine Excel actively prompting you with a pop up every time you open a sheet: "Do you trust the authors of this file? If not you will loose out on cool features and the sheet runs in restricted mode"
No it doesn't because restricted mode without Macros is the default and not framed like something bad or loosing out on all of those nice features,
Exactly that's why I was making the comparison, It's not a in your face PopUp, where users get used to just pressing the blue, highlighted and glowing "I trust the authors" button without even being told what features they'd miss out on.
The Protected view in Office instead tells you "Be careful" and to only activate editing when you need to.
It's also worth noting that this behavior evolved very slowly. It took Excel decades to learn how to best handle the defaults. Excel started with modals similar to VS Code's "Do you want to allow macros? This may be dangerous", found too many users self-trained on "Allow" as the only button that needed to be pressed and eventually built the current solution.
If VS Code is still on the same learning curve, hopefully it speeds up a bit.
Right, I think one of the biggest problems is the name "Restricted Mode" itself. It sounds like a punishment, when it is a safer sandbox. Restricted Mode is great and incredibly useful. But it is unsurprising how people don't like to be in Restricted Mode when it sounds like a doghouse out back, not a lobby or atrium on the way to the rest of the building.
Sure, but as noted elsewhere, the IDEs generally don't "do stuff" by default just on opening a file folder. VSCode, by default, will run some programs as soon as you open a folder.
It's worded really badly, so vscode is the thing that provides the dangerous features? No problem, I know and trust vscode. What the message should be warning about is that the folder may contain dangerous code or configuration values that can execute upon opening due to vscode features that are enabled by default. That sounds worse for them but that would be honest.
But you, as a security conscious software developer, know that the phrase "may automatically execute files" can also be "with malicious intent" - the tradeoff that whoever made the text (and since it's open source it's likely been a committee talking about it for ages) had to make is conciseness vs clarity. Give people too much text and they zone out, especially if their objective is "do this take home exercise to get a job" instead of "open this project carefully to see if there's any security issues in it".
This problem goes back to uh... Windows Vista. Its predecessors made all users an admin, Vista added a security layer so that any more dangerous tasks required you to confirm. But they went overboard and did it for anything like changing your desktop background image, and very quickly people got numb to the notice and just hit 'ok' on everything.
Anyway. In this particular case, VS Code can be more granular and only show a popup when the user tries to run a task saying something like "By permitting this script to run you agree that it can do anything, this can be dangerous, before continuing I'm going to open this file so you can review what it's about to do" or whatever.
- ESLint, the most commonly used linter in the JavaScript ecosystem uses a JavaScript file for configuration (eslint.config.mjs), so if you open a JS project and want your editor to show you warnings from the linter, an extension needs to run that JS
- In Elixir, project configuration is written in code (mix.exs), so if you open an Elixir project and want the language server to provide you with hints (errors, warnings and such), the language server needs to execute that code to get the project configuration. More generally it will probably want to expand macros in the project, which is also code execution.
- For many languages in general, in order to analyze code, editor extensions need to build the project, and this often results in code execution (like through macros or build scripts like build.rs, which I believe rust-analyzer executes)
Thanks! I think it would be better if these types of events were fine grained and you could decide if you wanted to run them the first time but I can understand them being enabled now.
More granular is more likely to train users on "Always Click Allow". The current modal dialog already has that problem and is just one O(N) dialog where N is the number of folders you open (modulo opt-outs). If you got O(N * M) of these where N is the number of folders and M is the number of tasks in tasks.json plus the number of Extensions installed that want to activate in the folder, a) you would probably go a little batty), and b) you would probably stop reading them quickly and just always click Allow.
(It can also be pointed out that a lot of these are granular under the hood. In addition to Restricted Mode as a generally available sandbox, you have all sorts of workspace level controls over tasks.json and the Extensions you have installed and active for that workspace. Not to mention a robust multi-profile system where you can narrow Extensions to specific roles and moods. But most of us tend to want to fall into habits of having a "kitchen sink" profile with everything always available and don't want to think about granular security controls.)
When you open up a folder in VS code, addons can start to set up language servers to index the code in the folder. This usually involves invoking build systems to set those up.
(I think some people are fixating on the specific feature that's mentioned in the article. The reason this pop-up exists is that there are many ways that this code execution could happen. Disabling this one feature doesn't make it safe, and this feature if not present, could still be achieved by abusing other capabilities that exist in the vs code ecosystem)
Makefiles etc. Many types of projects use arbitrary setup and build commands or can load arbitrary plugins, and unlike VS which imposes its own project format, VSC tries to be compatible with everything that people already use. Git hooks are another one.
Please see the reply to the other comment, obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.
Some project types, such as Gradle or Maven projects, use arbitrary commands or plugins in project setup. You have to run arbitrary plugins to know which directories are the source directories, and you have to know which directories are the source directories to do anything in Java.
If you just want to see the files in the directory, then sure. But VS Code is an IDE. It's made for editing software projects which have more structure than that.
The grand parent is talking about code execution can happen by just opening the directory, you’re imagining like I did (and the grandparent) that you have to run or execute something in VSC to get that to happen and I’m asking about what features could possibly require this to happen. Obviously running tests or a make file everyone understands clearly you’re executing other people’s code.
It’s not even running tests. Test extensions usually have to run something to even populate the tests panel in my first place and provide the ability to run à la carte. Thus opening a folder will cause the test collector binary to run.
They could ask and/or parse the tests for the information rather than run them to output it. I’m honestly still not seeing a killer feature here that makes the security implications worth it!
The trouble is that "just parse the tests" isn't always an option and running arbitrary code is the nature of how software is built.
The easiest example is JS testing. Most test harnesses use a JS file for configuration. If you don't know how the harness is configured how do you know you are parsing the right tests?
Most test frameworks in JS use the define/it `define("some test colection", () => it("some test", () => /* …test code… */))` pattern. Tests are built as callbacks to functions.
In theory, sure, you could "just" try to RegEx out the `define("name"` and `it("name"` patterns, but it becomes harder to track nesting than you think it is with just RegEx. Then you realize that because those are code callbacks, no one is stopped from building meta-test suites with things like `for (thing of someTextMatrix) { it(`handles ${thing}`, () => /* …parametric test on thing… */ }`.
The test language used most in JS is JS. It's a lot harder problem than "just parsing" to figure out. In most cases a test harness needs to run the JS files to collect the full information about the test suite. Being JS files they are Turing Complete and open to doing whatever they want. Many times the test harnesses are running in a full Node environment with access to the entire filesystem and more.
Most of that applies to other test harnesses in other languages as well. To get the full suite of possible tests you need to be able to build that language and run it. How much of a sandbox that language has in that case shifts, but often it is still a sandbox with ways to escape. (We've proven that there's an escape Zero Day in the Universal Turing Machine, escapes are in some ways inevitable in any and all Turing Complete languages.)
yeah me as well. at least have the untrusted code allow certain plugins or certain features of plugins to run that you whitelist. not having vim keybindings or syntax highlighting is too barebones.
The message isn't very clear on what exactly is allowed to happen. Just intuitively, I wouldn't have expected simply opening a folder would "automatically execute tasks" because that's strange to me
>Code provides features that may automatically execute files...
What features? What files? "may"? So will it actually happen or is it just "well it possibly could"?
I've used it to open folders that I personally made and which don't have any tasks or files that get automatically executed, and yet the message pops up anyway.
It's like having an antivirus program that unconditionally flags every file as "this file may contain a virus"
> What features? What files? "may"? So will it actually happen or is it just "well it possibly could"?
How is code supposed to know? It probably depends on the plugins you installed.
> It's like having an antivirus program that unconditionally flags every file as "this file may contain a virus"
No, it’s like if your OS asks if you want to actually run the program you’re about to before running it the first time.
And it gives you the alternative to run it in a sandbox (which is equivalent to what happens when you don’t trust the workspace, then it still opens but in restricted mode)
Yeah, because there are a lot of mechanisms by which a folder may start to execute code when you open it outside of restricted mode. A large fraction of addons have something which could be used for this, for example. There isn't a general check that it can apply ahead of time for this.
(They could, with some breaking changes, maybe try to enforce a permissions system for the matrix of addons and folders, where it would ask for permission when an addon does actually try to run something, but this would result in a lot of permission requests for most repos)
They could also, with a breaking change, enforce addons register what sorts of files they'll execute when a folder is opened in trusted mode. If no matching files are found, then opening the folder is safe and no prompt is needed. If matching files are found, then prompt the user and replace "may" with "will". Fewer permission requests, and a clearer message.
People will still inevitably ignore the message and open everything in trusted mode, but it'd be more reasonable to consider that user error.
Thing is, when you open a webpage it's clear that it may automatically execute code (Javascript, WebAssembly). What needs to be clear (and by default limited) is the authority of that code.
On Debian I actually get a surprising amount of packages from just the official repo. In Python or R, I could almost do a full analysis just with those packages. The smaller number of separately installed packages, I can at least do a superficial sanity check. An alternative model of doing things exists. Considering how infinitesimally small Debian is compared to Windows and MacOS, if we had more users, momentum, and volunteers, I have no doubt that I could do everything with well-tested packages only.
You don't really need more packages. There's definitely a culture of creating ridiculously small packages, though.
If you spend enough time in the ecosystem, you'll begin to realise that a select few are very well known for doing this; one in particular made a package for every ANSI terminal colour.
left-pad (and quite a few incidents afterwards) were definitely wakeup calls, and I like to think we've listened in some ways.
I do feel like better application sandboxing is needed but so much open source software is built on the Unix abstraction meaning you have to run in a container, but macOS doesn’t have containers as far as I can see, and containers themselves are a bit of a poor abstraction, although maybe the best we can do with Unix at the core. I think something closer to Roblox studio would be cool where when you open an environment stuff just spins up in the background, but there is a good debugger, logging, developer ide, good rendering, eg 3d graphics, separate projects are separate, and when you spin down a game (read app or project) everything spins down.
Yes, afaik macOS apps could theoretically be sandboxed as well (or close to) as iOS apps are.
You can find the policies for many first-party apps and deamons in /System/Library/Sandbox/Profiles. But in practice most third-party apps aren't.
It's a good idea so it can't take over your dev machine.
But not sufficient since it'll still F over whatever code you are working on resulting in a backdoored app getting deployed + infected dev scripts etc bringing interesting times to your teammates, downstream open source project users, your api keys and cloud credentials getting compromised etc.
I don't think it's viable to containerize an IDE. Running user code at full permissions is a core feature for an IDE. The programs that the user develops in an IDE could potentially touch any OS surface. When the user is a developer, you have to trust them.
Though this autorun feature is crazy and should be completely off by default.
Don't mark the folder as trusted when you open in VsCode. The number of other hooks that may exist is going to be hard to track down (especially because each addon may add their own).
This may only provide a flalse sense of security. Afaik, there is no way to disable workspace settings taking priority over user settings, so a malious repo can easily override them and reenable automatic tasks.
On macOS systems, this results in the execution of a background shell command that uses nohup bash -c in combination with curl -s to retrieve a JavaScript payload remotely
Unrestricted outbound connections, specially from curl/wget/bash
I think that's a bit ungenerous: there is a push and pull between security and seamless user experience and it's never obvious where the line should be set. You really only figure out which way to move it after someone complains.
I'm not sure about the other ones, but I know that helix supports language servers by default and it does not have a workspace trust system like vscode, so LSPs can automatically execute code when you enter a directory
> Coming from the perspective of an eclipse fan, why is VS code the defacto answer nowadays?
Is eclipse good now? I used it 15 years ago. It took ages to start. It was a memory hog and it was dog slow besides. My entire team got RAM upgrades on our computers because the default company issued machines (which were quite good at the time) didn't have enough RAM to use eclipse properly.
This is exactly what I was going to say. I used eclipse in college when learning Java. Back then it was bloated, slow, had really bad UX, and would occasionally crash for no reason I could ascertain (I was just doing basic school projects. Linked lists, binary search trees, etc...)
VS Code, although it is starting to go get a bit bloated, has always been extremely responsive and snappy. Yeah I've had it crash, but I was never surprised that it crashed. (e.g. opening enormous files, running several instances at once with tons of tabs open, long debugging sessions, etc...)
Definitely, it has been at least a decade since I had plugins corrupt my workspace, and there are old Reddit comments of me complaining about in on /r/java.
Load VSCode with the same amount of plugins, each requiring its own process, to see how "fast" it runs, not to mention Electron crap, there is a reason so many Microsoft plugins are actually written in C++ and Rust.
> It took ages to start. It was a memory hog and it was dog slow besides. My entire team got RAM upgrades
The more things change, the more they stay the same. I used to use VS Code on some very large C projects with 16GB of RAM, and my machine would grind to a halt while intellisense was indexing.
How much ram did you have, and when was this? I remember being extremely happy with Eclipse on an 8GB machine - this was back in the jvm7 days. Heck, I did jvm6 development with Eclipse on Windows XP with 4GB of ram and was content.
Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.
For years and years I had people telling me how great IntelliJ was, etc. I eventually switched - lo and behold, IntelliJ had just as many quirks (even some of the same) as Eclipse.
It was 2010. Our default work machines had 16gb of ram. Eclipse ran, but it was tight. Especially while debugging. Some developers also apparently liked to open a second eclipse instance for some reason. You'd go OOM pulling stunts like that.
They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE.
In eclipse's defence, we were working on a very large java codebase. But that shouldn't have been a surprise to anyone. I've never seen a java codebase come in any other size.
I'm running intellij (RustRover) right now, and its sitting on about 4.5gb of ram. That still seems very inefficient to me. But it doesn't sound that bad compared to eclipse.
At this time laptops still could have memory upgrades, and memory was pretty cheap compared to today. The first thing I did when I bought a new laptop was buying two 8GB SoDIMMs, it was way cheaper than ordering the upgrade from factory.
The thing is, memory in personal computer have plateaued for quite some time. 16GB was not uncommon in 2010. Things are not like the crazy 90s and early 2000s where PC configuration become obsolete in less than two years.
That seems incredible. 16GB of ram to run (presumably windows 10) and Eclipse?
Eclipse, unlike IntelliJ offers "project" view were you have have many "solutions" open at once. Even with multiple Eclipse instances open, it's hard to imagine it consuming so much ram.
Perhaps you had other company-required software running. I was working on relatively largeish codebases and very happy with 8GB of ram until 2018ish.
Regardless, an IDE is more than a text editor, so your claim that RustRover with 4.5GB of ram is inefficient is misguided.
>They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE.
Funny thing, memory was cheaper, and machines were upgradeable. People used to buy low memory machines and upgrade them with after market memory to avoid paying DELL or Apple's memory upgrade tax.
That's an absurd comparison, and you know it. Until an IDE actually performs some task that requires more advanced functionality, like analyzing a complex existing project to open without anything cached, compiling, profiling, etc. it is literally just editing text files. The only IDE that I use that takes anywhere CLOSE to the amount of time that Eclipse does to get moving is Unreal Engine. Any Jetbrains IDE, X Code, Visual Studio... all blow it away. I just opened a project in Visual Studio 2022 on a portability-focused laptop from 2018-- from click to the project open screen, it was about 3 seconds. From the project open screen to having an existing project completely open, it was 3 or so more seconds. On an 8 year old, tiny, not-optimized windows laptop.
I remember the first thing you had to do with eclipse was increase the memory limit so the obese hog called JVM could have barely enough room to wiggle around.
> Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.
My first IDE was Turbo Pascal 2.0, about 20 years before I used Eclipse, and I used a lot in between (and since). Eclipse was the single most unintuitive, user hostile, clunky, slow, and painful system to use. A few of those problems probably would have been a little bit less noticeable on a ridiculously high-end machine, but not all of them, and other contemporary IDEs worked well-enough on lighter machines. And despite how much I disliked using Eclipse, I liked the idea of Eclipse, and kept it around because it was, for a while, occupying the niche of “extensible open source platform most popular to target for interesting dev tools” (because there weren't really any alternatives that were as open and extensible).
I used eclipse in university around that time (2005), then first switched to netbeans which I already liked more, then discovered IntelliJ and have been using that ever since. Everything about Eclipse felt worse in ways neither of the others did, but all of that was still during university (though I now use JetBrains professionally).
Todays hard drives are faster then memory was back then, so it's probably not an issue now. Could probably reparse your entire code base at every key stroke without you noticing.
Modern PCIe NVME drives typically see a few microsecond latency, but even DDR2 latency was around 10 nanoseconds. Memory remains top dog by a long shot.
We used to have a custom Eclipse-derived tool for embedded development, and it sucked. Poor performance, crashy, difficult to build and debug. VS code is just lighter. As well as feeling more "modern", simply due to being built with the prejudices of the mid-2010s rather than the late 90s. Eclipse 1.0 was in 2001!
I switched to VSCode because it has a free editor with a really great jump to file hotkey.
I remember when the big VS added jump to file but it was so damn miserably implemented as to be useless.
Having worked at Microsoft for a decade, the most frequent way I navigated a large source tree was dir /s *partialfilename*.*
Then again while I was there, most code bases couldn't even open in Visual Studio. (highly team dependent, I was mostly on older C/C++ code bases.)
Some teams at MS paid for an editor called Source Insight, which indexed your code and could also parse C #defines and other preprocessor macros, which was super unique and powerful. It had an incredibly powerful symbol and fuzzy filename search capabilities, I'd frequently have Source Insight open just so I could find where in a folder structure a file was and then I'd open it up in my preferred editor.
Back when I got my first SSD the largest boost to my dev productivity was not in compile times (large C++ code bases tend to template bound more so than IO bound), it was how fast I could find files in the directory structure.
I'm sure Vi/Emacs users have some magic set of plugins that do all of this for them, but as someone back on Windows back in the 2000s and 2010s, the supported MS tooling was horrible at all this.
Then VS Code comes along with amazing fuzzy file name matching. Holy cow. Sure it is missing 90% of the power of real Visual Studio (being able to have a debugger step from front end web code to your backend and then into stored procedures in SQL, running on a remote machine, that your debugger transparently auth'd to, is something Microsoft had working 20 years ago and would be considered impossible dark magic with today's tooling), but wow can I navigate a project quickly!
Site license to source insight was something I missed badly after Microsoft. Bought my own copy. It did wonders when looking at Snowflake monorepo, which was otherwise impossible to understand . Great piece of software, still going strong too.
Same here! Easily jumping between files is one of the best features. I always have VS and vscode open simultaneously, doing about 99% of the work in vscode and only using VS to compile and to debug.
Eclipse is not safer it just has fewer people looking for holes in it. The problem is not the software but how we trust code from the internet. Even if you used Eclipse a fake recruiter could still trick you into running a bad script. We cannot fix social engineering by changing the text editor.
For me vscode is super-lightweight and at the same time has enough functionality. I didn't use Eclipse for many years, but from my memory it was super-heavyweight. And it didn't really support anything except Java.
Interestingly Java is the only language that I've found vscode support poor, so I keep buying Idea license exclusively for Java projects. For rest of languages that I use (JS/TS, Go, Python, Shell, YAML, XML) I'm using vscode and happy about it.
In recent years vscode starting to get bloated, mostly with AI stuff. But so far I can disable everything AI with a single setting and it works good afterwards. I'd prefer for all AI features to be contained in a separate plugin that I can just not install, but I guess managers these days want to shove AI in everyone's throat.
Another good thing about vscode is that its written with JavaScript and can be launched in browser, so in the future I want to put my development environment in the browser, but so far I didn't do that.
Or with most language specific extensions disabled by default.
I almost disable all extensions except the ones I use all the time. Then I enable specific ones at workspace level.
Yes, it's annoying. But as an extension author, I know how some badly written extension can significantly slow down the experience, both during startup and editing. I even profiled other people's extensions and submitted feedback.
Load time is in seconds, even with the program cached. I can still load vim with a ton of plugins[0] and still load a project in a few hundred milliseconds.
Maybe VS Code is faster with fewer plugins but it's still "dog slow" to load and run. Only thing I'm "missing" in vim is the bloat
[0] personal I only use a handful but I've played around because why not
With LazyVim (requires NeoVim) and its load-on-demand architecture, startup time usually stays below 50 milliseconds even with a ton of plugins. Below 50ms is fast enough that it feels instant. Aliasing `nvim` to `n` in my ~/.bash_aliases just makes it even faster. cd to a project directory, run `n .` and I'm looking at the NeoVim file explorer plugin for that project directory. No break in thought flow, no standing up to get coffee while the IDE loads, just keep going.
Your focus on startup speed feels really alien to me. When working on a project I just keep vscode open. I reboot maybe once a week and starting vscode again takes about a second, and then maybe 10s of seconds of background processing, depending on the project size, for the language server to become fully operational. That's more than good enough for me.
I've done a lot of shell-driven development in the 00s though, and I remember it did involve frequently firing up vim instances for editing just a single file. I no longer understand the appeal of that approach. Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
> starting vscode again takes about a second, and then maybe 10s of seconds of background processing
Yet I'm doing the same thing instantly or near instantly.
I don't reboot often and I'm still lazy and will leave projects open often, but honestly, have you considered that your workflow is an adaptation to the wait time?
> Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
I agree? But why do you think people don't fuzzy search in vim? Or the terminal? There's been tools to do this for a very long time. Fzf is over a decade old and wasn't the first
If you're using vim as an IDE (which is if course perfectly doable), then why does it matter if startup time is 50 or 1000 ms. You typically leave them running.
> Yet I'm doing the same thing instantly or near instantly.
Does vim somehow allow LSP servers to index faster? Or are you not actually doing the same thing?
Why are you leaving them running? Because they are slow to load?
Yes, Neovim supports LSP and it is very very fast.
I'm not sure why any of this is surprising. We're talking about the same company who is speeding up their file browser by loading it at boot time rather than actually trying to fix the actual fucking problems. Why is it surprising that everything else they make is slow and bloated as shit (even more as they've shoving AI into everything)
The point of LSP is that neovim is using the same servers for this as vscode. So I guess you work on smaller projects or with languages that have faster (usually meaning less fully featured) LSP servers.
LazyVim includes a bunch of pre-configured plugins that turn NeoVim into an IDE. Fuzzy search by filename, search by text, file explorer, go to definition, go to reference... Even debugging and unit test runners, it's all there. Yet when I'm at the command line and I need to make a quick edit to one file, e.g. `nvim ~/.bashrc`, I don't pay the startup cost of waiting for 50 plugins I'm not going to use. So it's the best of both worlds.
>>Load time is in seconds, even with the program cached.
Are you like, for real? How often do you load it up for it to matter in the slightest? Do you not just open the project once at the start of the day and then continue working?
Sorry but for someone used to working in VS proper and projects which take minimum 40 minutes to build, saying that a startup time of a few seconds is a problem is.....just hard to understand.
I live in the terminal and opening files with vim is the primary way I interact with them.
> Do you not just open the project once at the start of the day and then continue working?
I mean I do this too
> projects which take minimum 40 minutes to build
This sounds problematic and a whole different category of problems.
Don't you have partial compiles? Parallel compiling? Upgrade your machine?
But it's not just startup time. I use less RAM, less CPU resources, jumping through tags is instant, working through the debugger is instant, opening new files is instant, fuzzy searching my system is instant. It sounds like the program you're working on and your editor are fighting for resources and I've never faced that problem with vim
>>Don't you have partial compiles? Parallel compiling?
We do. Without it it it takes over 3 hours for a full project build. Normally if I change one line of code and hit "run" it takes ~10-15 minutes for the app to start, depending on which file I changed.
>>Upgrade your machine?
It's a 64 core/128 thread core Threadripper workstation with 256GB of ram, so not many upgrade options from that.
It's a huge C++ project, heavily templated, that's kinda normal. My previous 2 projects were also like this.
Lol this isn't unique nor out of the norm - most big C++ projects are like this, and certainly every one in my industry(video games), unless you're trying to make an argument that C++ is somehow not commonly used. I even worked on a small indie game in C++ and it took 5 minutes minimum to compile.
C++ is common, but game programming definitely isn't the norm.
And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant
I've also worked on systems which are entirely written with template metaprogramming. This is definitely not the norm. Though that code was highly focused on optimization, as we were writing for HPC environments (extremely heterogeneous hardware). Sure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane. A partial compile of a few minutes usually meant my time was better spent mucking about with the cmake and build files because incremental testing sped up development and your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.
>>C++ is common, but game programming definitely isn't the norm.
I mean, last time I checked there are hundreds of thousands of programmers working in this industry, and video games are a bigger industry than movies. What's not the norm about it, exactly? I imagine there's more programmers out there making video games than making accounting software, for example.
>>And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant
I'm sorry, I'm confused. Did I ever imply otherwise? Maybe let me say it again, clearer - so far I worked at 2 big AAA studios, on 5 big AAA franchises, in 4 different engines. All 5 of those had those multi-hour compilation times unless you used something like Incredibuild or Fastbuild, and every single one of them had a startup of around 10+ minutes if you made any change to the code at all, just for VS to finish compilation and linking. I also worked at a small indie studio, with its own C++ engine, we had maybe...200 files max? That project took 5 minutes to build. Don't know where you got the idea that I'm saying factor of 8 is insignificant.
>> your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.
Hmm at the current project the time from me submitting a change to it actually being accepted is ~6 hours. On my previous projects I think the fastest I've seen has been around an hour for a very very quick preflight. But then all the tests also have to pass which takes a lot of time.
>>ure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane.
Right, but you have to do this at least once when you get latest, normally in the morning I grab latest and have to build around ~9000 files. If I make a change in the gameplay code it might have to recompile ~200-300 files because of the dependencies on all the associated systems.
Seems very odd to me that someplace would force the use of a particular development tool. I've seen it only one time while interviewing, where they wanted everyone to have identical setups so they could easily hop onto each others computers when needed... it was weird and I took it as a red flag and didn't follow through them them.
Some software development workflows require specific tooling, with complex setups. While it may be possible to do with other tools, it's often very difficult, and not really worth the trouble when there is a known working setup. It's easier to onboard new people if they use the established toolchain with known working configs. I worked at a place once where it took several days to get the dev environment set up. It would have taken far longer if someone wanted to use whatever random tool they'd prefer to use.
If you code in embedded systems or FPGA its very common since you are using very specific vendor tools. A lot of enterprise companies have a "one way" kind of philosophy as well, they lock down the systems so much "for security" that you might not be able to install anything other than Eclipse or whatever is approved.
Wanting to be able to use anybody's machine is very strange, agreed.
From a support/IT perspective though, the closer everybody's machine is, the easier the job is.
The last software shop I worked at, we had a default set of tools and configs. It was a known happy path. You were allowed to adventure off of that path, but you were mostly on your own.
Devcontainers[1] or some similar technology are a must. Use whatever specific IDE you want, but the development environment itself should be identical across everyone on the team.
No more "works on my computer" issues. The environment is always identical.
> Wanting to be able to use anybody's machine is very strange, agreed.
Very useful if people are struggling to create reliable repro steps that work for me - I can simply debug in situ on their machine. Also useful if a coworker is struggling to figure something out, and wants a second set of eyes on something that's driving them batty - I can simply do that without needing to ramp up on an unfamiliar toolset. Ever debugged a codegen issue that you couldn't repro, that turned out to be a compiler bug, that you didn't see because you (and the build servers) were on a different version? I have. There are ways to e.g. configure Visual Studio's updater to install the same version for the entire studio, which would've eliminated some of the "works on my machine" dance, but it's a headache. When a coworker shows me a cool non-default thing they've added a key binding for? I'll ask what key(s) they've bound it to if they didn't share it, so we share the same muscle memory.
It's quite common if you work in a team of engineers, or in a large company with many engineers.
Having consistent machine and OS and app configurations enables better (lower cost, higher reliability) scripting and tooling solutions in things like repos and infrastructure.
Not unlike consistency in language and compiler choices.
Having a consistent setup makes it easier for your organization's IT team to support you, troubleshoot issues, etc. It also makes it easier for you to collaborate with other members of your team, or even other teams. If your coworker Fred comes to you asking for help on how to refactor something, for instance, it will go much more easily if you're running the same IDE with the same refactoring tools.
Organizations establish and enforce standards for a reason.
I don't really like VS Code either, but I personally use it because I tend to jump between a half-dozen semi-obscure languages, and VS Code is the only [0] editor that supports all of them.
[0]: Vim and Emacs have almost as good or slightly better language support, but I prefer GUIs over TUIs.
Eclipse was always a confusing product. It was a bastard child of Visual Age for Java from IBM, which was already a bastard of IBM's Visual Age for Smalltalk.
Visual Age for Java had some quirkiness being a Smalltalk IDE adapted to Java development (for example, the concept of a file and a hierarchical filesystem itself was definitely a second class citizen in Visual Age) and eclipse kind of rounded those rough edges.
But Eclipse became a victim of late 90s/early 2000s academic driven overengineering with overly complex/bureaucratic stuff like OSGI, and the support for the absurdly bureaucratic java development ecosystem at that time.
Never liked Eclipse, but I’ve been forced to use VSCode over my preferred JetBrains IDEs because it is the only modern mainstream editor with a competent client-server mode. As in, actually rendering the UI locally while doing all the code indexing and intelligence on the server. Corporate world would much rather maintain disposable remote VMs than help you unfuck your laptop after whatever required security upgrade installs the wrong version of a scripting language and sends everything to hell.
It’s not as dumb a client as VNC, but it’s close. Basic operations like typing and scrolling will stutter and lag if your connection is less than perfect. VSCode’s client is really VSCode from a UI perspective.
They're not using the remote VM as a server but as the development machine though. You don't want to have to git commit and push every time you need to run or even type-check your code.
I think what GP describes is actually a pretty okay solution for orgs that don't want to provider their devs with local admin privileges.
You can develop locally if you want to, and lots of people do, but it’s community support. The environment that someone else is obligated to fix for you is the remote one (which they can do by blowing away the container and then you recover your state from Git).
To myself and many others, vscode is not the defacto answer. JetBrains is. IntelliJ was miles ahead of eclipse last time I checked. Rider is miles ahead of Visual Studio. WebStorm is miles ahead of vscode for js etc.
It's not even a competition, to me. I've had to use Visual Studio instead of Rider for work the past year and it's been a very bad experience.
The biggest difference is JetBrains intellisense feels like it's reading my mind, I'll just type a couple characters and hit tab most of the time. Visual studio on the other hand has the worst intellisense I can imagine. It very frequently just messes up what I'm doing - I'll write what I want correctly, hit space and VS will just change it to something entirely different and import a package while it's at it. It's incredibly annoying. And when I actually want to use auto complete, say for example I've declared a variable on the line above and I want to use it, I'll write a couple characters and then without fail the variable I just declared on the line above is like option 6 down the list behind a bunch of crap that doesn't even make sense in the context at all. And as if it wasn't enough that the IDE is crap when it's working correctly, it very frequently craps out and just stops providing syntax highlighting and such in .razor files, or showing errors in files that compile just fine, forcing me to restart it and delete the .vs folder. Like every day.
Personally I think the only people who prefer other products than JB are people who don't know what they're missing. JB is literally just better in pretty much every way. At least the products I've used. I think I'll turn down the next job that asks me to use VS.
I’ve never written a line of Java in my life. Why would I ever use Eclipse?
VSCode is defacto standard because it’s kinda mediocre but works ok enough for every language and every platform. Microsoft created and popularized LSP so VSCode isn’t a single language IDE.
I use a mixture of code editors. My favorite is probably 10x but it only works with C++. So VSCode is just a reasonably standard unless a different editor is better for a specific use case.
The only thing that matters is extensibility/customization and speed. I want the lightest, most customizable thing that isn't emacs (for real reasons, trying to set up emacs at work is too much of pain in the ass) as my single pane of glass on any OS I care to use. If it can't do that, it doesn't live long.
Thing that IntelliJ and even NetBeans have going for them is that they seem like tools for getting work done. Eclipse puts more emphasis on being a platform which means you have to download and configure plugins just to get started. Great if you're a corporate shop with a standard setup that's force-pushed to every machine. Not so much if you're just getting started or working on side projects or in a startup, which is how languages and frameworks gain mindshare in the web era.
Visual Studio Code—I dunno. It's an editor more than an IDE. It lets Webdev Andys create an empty directory, put an index.ts in there, and get started right away. Yes, WebStorm does the same, but VS Code comes with decent multilanguage support for free. It's like vim or Emacs but crappier and more bloated, but a lot of people don't care about that.
I've also used Eclipse in the past but almost exclusively used vscode in recent years. It's just a phenomenal text editor. It's got fantastic multi-line selection and editing tools and searching for files is instant and you don't even need to be fully accurate with the filename. Nowadays I hardly ever use the sidebar to look for the file, I just type thr ctrl+e shortcut and insert several letters of the file and I instantly get the result. It's a small thing with a huge impact. VS, for comparison, lags a few seconds when searching files, and it misses files that are not imported into the workspace. That difference makes VS useless to me.
I stopped using it because none of the plugins for the languages I was using at the time (Ruby, Python, Erlang) were either worth a damn, or getting updated to track new language features.
I started using VSCode because IntelliJ-family IDEs will report incomplete search results as complete when they are rebuilding their search indices. To put it another way, they will tell you that a string that definitely appears in the project does not appear, if they haven't gotten around to re-adding the files that contain that string to the search index.
This to me is intolerable behavior. Others find it perfectly acceptable.
I bucket Eclipse under "heavyweight IDE". I used to use it, plus the CDT plugin, for my C++ nonsense.
Then Visual Studio's Express and later Community SKUs made Visual Studio free for ≈home/hobby use in the same bucket. And they're better at that bucket for my needs. Less mucking with makefiles, the mixed ability to debug mixed C# and C++ callstacks, the fact that it's the same base as my work tools (game consoles have stuff integrating with Visual Studio, GPU vendors have stuff integrating with Visual Studio, the cool 3rd party intellisense game studios like integrates with Visual Studio...)
Eclipse, at least for me, quickly became relegated to increasingly rare moments of Linux development.
But I don't always want a heavyweight IDE and it's plugins and load times and project files. For a long time I just used notepad for quick edits to text files. But that's not great if you're, say, editing a many-file script repository. You still don't want all the dead weight of a heavy weight IDE, but there's a plethora of text editors that give you tabs, and maybe some basic syntax highlighting, and that's all you were going to get anyways. Notepad++, Sublime Text, Kate, ...and Visual Studio Code.
Well, VSC grew some tricks - an extension API for debuggers, spearheading the language server protocol... heck, I eventually even stopped hating the integrated VCS tab! It grew a "lightweight IDE" bucket, and it serves that niche for me well, and that's a useful niche for me.
In doing so, it's admittedly grown away from the "simple text editor" bucket. If you're routinely doing the careful work of auditing possibly malicious repositories before touching a single build task, VSC feels like the wrong tool to me, despite measures such as introducing the concept of untrusted repositories. I've somewhat attempted to shove a round peg into a square hole by using VSC's profiles feature - I now have a "Default" profile for my coding adventures and a "Notes" profile with all the extensions gone for editing my large piles of markdown, and for inspecting code I trust enough to allow on disk, but not enough to autorun anything... but switching editors entirely might be a better use of my time for this niche.
I would say the answer is that's not the general perception of the software. I'm personally migrating out of VSCode, because having to use the OpenVSX registry to have open-source builds makes me mad (I've since migrated to Zed for now, since I've never adapted well to neovim nor emacs).
In general, I believe most people see VSCode as "good enough". Maybe not the best text editor, but it's good enough at everything it does and extensible enough to the point that there's really no point to go for anything else unless you have a really good reason to.
> Im guessing the answer is probably Java is why eclipse is out of favor.
My previous answer is thinking about editors in general. But in the case of Eclipse I'd say you're right LOL.
People forget that there was a period of time during which the Java runtime installer tried to install actual adware. You had to jump through hoops to deselect adware from being forced onto your machine, it was infuriating.
Setting up a new machine, I could choose between Eclipse (free, took forever to open, slow, asked me a million questions before it let me start working) or Visual Studio (cost money, incredibly powerful, written in C++ and was really damn fast.)
Back in 2005 it was mostly in C++ and it was blazing fast. IMHO VS 2005 was the most performant edition. I never liked VS 2003, felt bloated in comparison.
It's the license. The MIT license is what makes VSCode the defacto answer.
It also runs on the web, which makes it extremely convenient to toss into...web things. It's the code editor for the Google Cloud console, the Lambda web console, the GitHub web editor, and so on.
I'm going to guess that Eclipse doesn't have the same amount of security issues because it's not a popular target. Everyone (relatively speaking) is using VSCode or something based on it.
As I remember it, VS code was Microsoft’s response to Sublime.
Sublime was exceptionally popular for web developers throughout the 2010s.
Sublime was maintained by a single person as far as I know.
VS code was pretty much a copy of Sublime but with a much better extensions system and relatively quickly there were some great plugins that made VS code the de-facto editor for web development.
Yes, Atom was an earlier shot at building a Sublime competitor too.
I don’t know how usage of Atom compared to Sublime, but within my friends and colleagues it was only when VS code got good that people started moving away from Sublime.
I can only speak for $MY_JOB, but I'm pretty sure everyone was on Atom before VSC "got good". Atom had a good plugin ecosystem; what really drove the change was Atom's horrible performance issues whereas VSC was snappy and responsive.
What I believe also influenced the shift was that at that point in time MS had accumulated a decent amount of developer trust by giving us TypeScript and later on by acquiring GitHub. They appeared to care and have the right vision for open source.
Nope it started as a Web IDE, going against Atom was their pivot to win market share, there are a few talks from the team if you search for VSCode history.
It just happens. I was happy on netbeans, then I was forced over to eclipse, which I got used to. Then I got forced over to intellij. I'm still pissed about that (even though it's rider for me these days).
I don't mind VSCodium that much because I can put my tooling on the side (like a good unix fanboy) instead of hoping that jetbrains reimplements every other tool. Ag, grep beat IDE searches any day.
But yeah we have reach a stupid point in the industry where VSCodium asks me to trust a codebase before it will let me edit it.
I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files.
If you have a jumphost chain, you can configure that in the SSH config.
I don't know what a devcontainer is exactly, but if it's a container in the sense that it runs a Linux development system, I would investigate whether that, too, could easily be set up for access via SSH or mounted locally through some other mechanism.
File access isn't the same as tool access. You need to run tools on your ssh host as well. And a devcontainer does indeed equal a (docker) container. The name is very specific and describes shipping a full developer environments so that 'you' do not have to install gcc-toolset-15, or boost 1.83, or mold, or python 3.11, and so on.
If you did webshit in eclipse, especially with NPM involved, it would be just as bad. Running arbitrary code from a downloaded bundle seems normal in that world.
> Im guessing the answer is probably Java is why eclipse is out of favor.
I don't get the connection, but Java had log4j, i.e. a remote code execution vulnerability.
This is so insane to me. Eclipse is... Fine for Java in the sense Visual Studio is for dotnet. But man can they both be slow.
Use case depending sometimes you just need a quick editor, thats why sublime had and probably still has a huge userbase, its fast startup and flexibility. Vim, emacs and derivatives of it are the same story.
I can't imagine ever opening up eclipse to edit a zig/go/js file or project. It's too bloated.
The answer is neovim anyway. That's all anyone needs. /s
Emacs is a full IDE, not just a quick one-off editor. Its power comes from having everything scriptable from the ground up. Contrast this with the modern Extension concept, where there is a hard line between the editor's code and any changes you might want to make to its behavior.
I think vim is probably similar, but I've not gotten into it that much.
It is scary that a text editor can run hidden code just by opening a folder. We traded our safety for convenience and now we are paying the price. Users will always click the button to trust a file if they think it helps them work faster. We cannot blame them when the software design makes it so easy to make a mistake.
Bah. It's what chrome on Android is doing now when I ask it to give me the link. Fixed it. Thanks!
I had searched for it in the search bar at the bottom of the home screen, which opened it in a chrome window. If you tap the share icon on the top right, you get the share.google link. If you tap the three dots and then something like "copy link" you get the actual link.
You are right that the computer asks you. But people click yes because they are used to ignoring warning signs. The software relies on people making perfect choices every time and that never happens.
It should tell me what should I look before I trust it. Not trusting the workspace means I might as well use Notepad to open it. I wouldn't think that tasks.json include autorun tasks in addition to build actions.
I'm big on user first, if that dialog had sirens blaring, a gif and ten arrows pointing that "THIS MAY EXECUTE CODE" and people still didn't get the idea, I'd say it needs fixing. It can't be said that they didn't try or that they hid it though.
So at the end of the day its still unclear whether it executes code or not? Just say "this WILL execute code" and specify exactly which code it tries to execute by default.
I don't know about you people, but I always read this as "it may execute code if you run a build step".
Not "I will execute autorun.inf like an idiot."
And NO. I do not want my IDE to execute code when i open files for editing. I want it to execute code only as part of an explicit step that I initiate.
It's not a false choice - "Trust" and "don't trust" are both perfectly viable options. The editor works fine in restricted mode, you just won't have all your extensions enabled.
Not a VSCode user, so a genuine question: what are practical use-cases in which you want VSCode to automatically execute a task only by opening a folder?
Is it only for convenience so it already `npm i` or `npm start` without you having to do anything, or are there any other legitimate purposes beyond that?
Apart from this feature specifically, in general people would like their IDE to run language servers, set up build systems, and any number of other things which are likely to require some configuration which allows executing some code in the folder to work. VS code has a restricted mode to prevent this, which you need to accept a dialog to disable, but it also disables most of its features.
> in general people would like their IDE to run language servers, set up build systems, and any number of other things
That I understand, I’m mainly wondering why all that would have to happen automatically by merely opening a folder.
My personal preference may differ here, but for things like running a build or starting a dev server, I usually prefer to trigger them manually, and not have them silently executed only by me browsing through the sources.
Therefore I’m trying to understand whether there are legitimate use-cases for this “auto-run on open folder” feature besides the obvious convenience aspect of saving one or two extra clicks.
When I used it, the one use case I used it was to automatically launch a Jekyll server - if I'm working on a site I'm almost certainly going to want to look at my changes in the browser. Now that I've switched I just run one extra command, it wasn't a big saving, but it was kind of nice.
The article doesnt' claim it's executed straight up either ("can result") but it's pretty ambiguous:
> When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system.
In the screenshot the task is named "node" - so it's a bit like embedding a malicious Makefile target as a backdoor.
Except harder to spot since it's in a obscure .vscode/somethingsomething json file. (And probably you can easily fool GH Copilot to run it)
In tasks.json, which I use for automatically `git fetch`ing on a few projects. While I don't recall it's interaction with first run / untrusted folder dialogs, it's entirely automatic on second run / trusted folders.
Does it matter that much? I don't think there is any "safe" build system. Users will try to build project sooner or later. With Maven it is easy to add a plugin with harmful payload as dependency, you won't spot it in "source", unless you carefully review every dependency. IDEs need containers/isolation and they need it now. Instead we got that "Do you trust this project" dialog.
I'm moving all my development to a remote VM so I can use a coding assistant without worrying too much. I use VS Code's "Remote - SSH" plugin to connect.
I'm wondering if that helps. If I "trust" a remote directory, is there an exploit that can get to my laptop?
There's enough complicated machinery that I'm thinking the answer is likely yes, but perhaps this has been vetted.
Is this 'task' feature really useful? I'd say applications like IDEs and text editors should not have automatic arbitrary execution of code in the first place. 'eval' should be blocked and extensions/plugins should have only very limited power to execute external logic (such as processes for LSP) or require allowlisting manually every process.
I am fully moving from local electron based vscode to using vscode-server inside docker inside a vm. It has just so many advantages besides security eg. being able to have multiple workspaces in tabs instead of separate electron windows, and having all the docker/vm tooling available. This can replace remote vscode, devcontainers and electron in a nice package. There is just no reality in which vscode with electron running as user account on a bare machine can be secure not even thinking about agents in the mix. We are working on a custom browser called darc based on chromium IWAs and controlled frames instead of electron and optimised for this. (apache 2.0)
Maybe I'm a dinosaur in this regard but I don't like nor trust any of these desktop application that are really just Web technologies with an embedded browser eg Discord.
They're resource hogs and the attack surface is huge. You're basically betting that automatic code that's run won't find a vulnerability and escape the sandbox from an entire browser.
I have way more trust in Jetbrains IDEs and the JVM as a sandbox vs HTML/CSS/JS.
Still, I'm always impressed at the ingenuity of the people who come up with these attacks and the people who find them.
Won’t IDEA automatically index/execute some Gradle code when possible? As soon as you execute an arbitrary binary/script from the project directory, the isolation of the JVM doesn’t matter.
This particular vulnerability relied upon passing the require function to a scope to allow the loading and running of arbitrary code. This is what I tend to call a blacklist approach. You're saying in this sandbox certain features can't be used because they will allow escape.
The alternative is a whitelist approach. Instead of disallowing dangerous features you're enabling only the features you need.
So a build system like Gradle or Maven (same thing really) has a limited set of primitives it is allowing access to. It's not loading, say, the entire JVM and all the Java core libraries and then listing all those you can't use.
You see the difference? If nothing else, the blacklist approach is going to fail when the virtual machine (or whatever) adds a new API call upstream and it's added without intent to the sandbox by simply doing an update where nobody has thought to disable it.
Another way of looking at this is Gradle isn't being compiled into Java bytecode and run in the same environment as the IDE (sandboxed or otherwise). That is inherently riskier.
Yep. You’d think using web tech would make it really easy to sandbox any 3rd party JavaScript that gets run. But I suppose sandboxing is simply too inconvenient.
Because that isn't how it happens, the plugin model relies on external processes with OS IPC, most of them rely on basic process security model, and aren't even implemented in JavaScript due to performance.
What is the risk profile when running untrusted code in a GitHub codespace under VS Code (other than access to and env vars or secrets attached to the code space)?
"Code provides features that may automatically execute files in this folder. If you don't trust the authors of these files, we recommend to continue in
restricted mode as the files may be malicious."
If you proceed with "Trust Project" you're at your own fault.
You know what would be better? Telling me explicitly what file/script will run and asking permission for that. A blanket message every time is no better than the cookie popups and doesn’t tell me if the project has 0 files that will run.
The "trust project" feature has been designed to be so extremely intrusive and annoying that the first thing I do is to completely disable it whenever I install VS Code on a new computer. This "solution" was just done to tick some box and put the blame on the user when a security incident happens. It's pretty similar to Windows Vista where it annoyed you with a disruptive popup so many times during the normal course of actions that most people ended up disabling the whole UAC system. Overall security goes down, and Microsoft has a nice excuse.
> It's pretty similar to Windows Vista where it annoyed you with a disruptive popup so many times during the normal course of actions that most people ended up disabling the whole UAC system.
Nothing changed post-Vista. It's exactly the same system in Windows 11 doing exactly the same thing. It did, however, get developers to change how they do things.
To be honest, the solution here is probably more dialogs like this, not less. Having one single "Trust everything here but if you don't then nothing will work" box is hardly a good way to go.
Vista's annoyance had a purpose, to get program developers to change things to run without escalation. They didn't want you disabling UAC, and these days it breaks things to disable UAC.
By only having an upfront project-wide toggle, VS Code is much worse.
Yeah imagine if at boot Windows Vista gives you the UAC "Do you TRUST all the software you are going to run today?" and if you say yes then it just allows any random code to do whatever it wants.
Agree. But the first build you do after that clone/checkout is risky too. Maybe not as wide open, as the build-tool makers are a line of defence if they're acting on classes of vuln.
When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system.
Sigh. It's so Microsoft to just run random stuff.
Of course, in the Linux world, we have "Install with"
VS Code team member here :wave:
As called out elsewhere, workspace trust is literally the protection here which is being circumvented. You're warned when you open a folder whether you trust the origin/authors with pretty strong wording. Sure you may find this annoying, but it's literally a security warning in a giant modal that forces you to chose.
Even if automatic tasks were disabled by default, you'd still be vulnerable if you trust the workspace. VS Code is an IDE and the core and extensions can execute code based on files within the folder in order to provide rich features like autocomplete, compilation, run tests, agentic coding, etc.
Before workspace trust existed, we started noticing many extensions and core features having their own version of workspace trust warnings popping up. Workspace trust unified this into a single in your face experience. It's perfectly fine to not trust the folder, you'll just enter restricted mode that will protect you and certain things will be degraded like language servers may not run, you don't be able to debug (executes code in vscode/launch.json), etc.
Ultimately we're shipping developer tool that can do powerful things like automating project compilation or dependency install when you open a folder. This attack vector capitalizes on neglectful developers that ignore a scary looking security warning. It certainly happens in practice, but workspace trust is pretty critical to the trust model of VS Code and is also an important part to improve the UX around it as we annoy you a _single_ time when you open the folder, not several times from various components using a JIT notification approach. I recall many discussions happening around the exact wording of the warning, it's a difficult to communicate concept in the small amount of words that it needs to use.
My recommendation is to use the check box to trust the parent or configure trusted folders. I personally have all my safe git clones in a dev/ folder which I configured to trust, but I also have a playground/ folder where I put random projects that I don't know much about and decide at the time I open something.
I suspect that you're relying too heavily on the user here. Even for myself, a very experienced developer, I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment. I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it". Expecting us to surface from our flow, think about the risks and make an informed decision might on the surface seem like a fair expectation, but in the real world, I don't think it's going to happen.
Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state. But now you're relying on people to have known about the question beforehand, and have this strategy worked out ahead of time.
If you're going to rely on this so heavily, maybe you should make that strategy more official, and surface it to users ahead of time - maybe in some kind of security configuration wizard or something. Relying on them to interrupt flow and work it out is asking too much when it's a security question that doesn't have obvious implications.
> I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment
Maybe I'm too close to it, but the first sentence gives a very clear outline of the risk to me; Trusting this folder means code within it may be executed automatically.
> I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it".
I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
> Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state.
You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
> Trusting this folder means code within it may be executed automatically.
But as you point out elsewhere, what constitutes code is very context dependent. And the user isn't necessarily going to be sufficiently expert on how Code interacts with the environment to evaluate that context.
> I'm curious what would stop you from opening it in restricted mode?
Even after years of using Code, I don't know the precise definition of "restricted mode". Maybe I ought to, but learning that isn't at the top of my list of priorities.
> You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
NO! Not even close! And maybe this is at the heart of why we're not understanding each other.
My goal is not to run an editor and change some characters, not at all. It's so far down the stack that I'm scarcely aware of it at all, consciously. My goal is to, e.g., find and fix the bug that the Product Manager is threatening to kill me over. In order to do that I'm opening log files in weird locations (because they were set up by some junior teammate or something), and then opening some code I've never seen before because it's legacy stuff 5 years old that nobody has looked at since; I don't even have a full picture of all languages and technologies that might be in use in this folder. But I do know for sure that I need to be able to make what edits may turn out to be necessary half an hour from now once I've skimmed over the contents of this file and its siblings, so I can't predict for sure whether whatever the heck "restricted mode" will do to me will interfere with those edits.
I'm pretty sure that the above paragraph represents exactly what's going on in the user's mind for a typical usage of Code.
Good point about one off edits and logs, thanks for all the insights. I'll pass these discussions on to the feature owner!
Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"?
In light of this vulnerability, the team may want to revisit some of these assumptions made.
I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this workspace?' and hit the big blue "Yes" button to quickly just get to work.
With AI and agents, there are now a lot of non-dev "casual" users using VS code because they saw something on a Youtube video too that have no clue what dangers they could face just by opening a new project.
Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).
Didn't mean to come off that way, I know a lot of the decisions that were made. One thing I've got from this is we should probably open `/tmp/`, `C:\`, ~/`, etc. in restricted mode without asking the user. But a lot of the solutions proposed like opening everything in restricted mode I highly doubt would ever happen as it would further confusion, be a big change to UX and so on.
With AI the warning needs to appear somewhere, the user would ignore it when opening the folder, or ignore the warning when engaging with agent mode.
> Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).
I’m not sure this is possible or non-misleading at the time of granting trust because adding or updating extensions, or changing any content in the folder after trust is granted, can change what will be executed.
For what it's worth, I absolutely agree with the comments saying the warning doesn't clearly communicate the risks. I too had no idea opening a directory in VS Code (that contains a tasks.json file) could cause some code to execute. I understood the risk of extensions but I think that's different, right? i.e. opening a trusted project doesn't automatically install extensions when there's an extensions.json (don't quote me on that, unless that's correct)
To give some perspective: VS Code isn't my primary IDE, it's more like my browsing IDE. I use it to skim a repo or make minor edits, without waiting for IntelliJ to index the world and initialize an obscene number of plugins I apparently have installed by default. Think—fixing a broken build. If I'm only tweaking or reinstalling dependencies because the package-lock file got corrupted and that's totally not something that happened this week, I don't need all the bells and whistles. Actually I want less because restarting the TypeScript service multiple times is painful, even on a high end Mac.
Anyway enough about IntelliJ. This post has some good discussions and I sincerely hope that you (well, and Microsoft) take this feedback seriously and do something about it. I imagine that's hard, as opposed to say <improving some metric collected by telemetry and fed into a dashboard somewhere>, but this is what matters. Remember what Steve Ballmer said about UAC? I don't know if he said anything, but if it didn't work then it's not going to work now.
> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
Have you tried it? It breaks a lot of things that I would not have expected from the dialog. It’s basically regressing to a slightly more advanced notepad.exe with better grepping facilities in some combinations of syntax and plugins.
Isn't that what you would want if you're opening an untrusted codebase?
No, I want syntax highlighting.
In the past, editors could give me syntax highlighting without opening me to vulnerabilities.
Syntax highlighting works perfectly fine in Restricted mode, at least for me.
Perhaps you have some settings you can adjust in your install to get that working?
Check the docs on this page: https://code.visualstudio.com/docs/editing/workspaces/worksp...
> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
loss of syntax highlighting and to a lesser extent the neovim plugin. maybe having some kind of more granular permission system or a whitelist is the answer here.
opening a folder in vscode shouldn't be dangerous.
> opening a folder in vscode shouldn't be dangerous.
You're not "opening a folder" though, you're opening a codebase in an IDE, with all the integrations and automations that implies, including running code.
As a developer it's important to understand the context in which you're operating.
If you just want to "open a folder" and browse the contents, that's literally what Restricted mode is for. What you're asking to do is already there.
I've been using VS Code for many years and I try pretty hard to be a security aware dev.
I checkout all code projects into ~/projects. I don't recall ever seeing a trust/restricted dialogue box. But, I'm guessing, at some point in the distant past, I whitelisted that folder and everything under it.
I've only just now, reading through this thread, realized how problematic that is. :o/
Syntax highlighting should work if the highlighting is provided by a textmate grammar, it will not work if it's semantic highlighting provided by an extension and that extension requires workspace trust. If it's possible to highlight without executing code, that sounds like an extension issue for whatever language it is. I believe extensions are able to declare whether they should activate without workspace trust and also to query the workspace trust state at runtime.
The funny part is that everyone expects you to make an informed decision about your security, without even providing any data to make that decision.
A better strategy would be:
- (seccomp) sandbox by default
- dry run, observe accessed files and remember them
- display dialog, saying: hey this plugin accesses your profile folder with the passwords.kdbx in it? You wanna allow it?
In an optimum world this would be provided by the operating system, which should have a better trust model for executing programs that are essentially from untrustable sources. The days where you exactly know what kind of programs are stored in your folders are long gone, but for whatever reason no operating system has adapted to that.
And before anyone says the tech isn't there yet: It is, actually, it's called eBPF and XDP.
You also get problems with overwarning causing warning fatigue. Home Assistant uses VS Code as its editor (or at least the thing you use to replace the built-in equivalent of Windows Notepad) and every single time I want to edit a YAML config file I first have to swat away two or three warnings about how dangerous it is to edit the file that I created that's stored on the local filesystem. So my automatic reaction to the warnings is "Go away [click] Go away [click] Go away [click], fecking Microsoft".
I’d like more granular controls - sometimes I don’t want to trust the entire project but I do want to trust my elements of it
How is this any different than anything else devs do? Devs use `curl some-url | sh`. Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.
At some point the dev has to take responsibility.
Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.
You allow developers to download and run arbitrary packages? Where I came from, that went out years ago. We keep "shrinkwrap" servers providing blessed versions of libraries. To test new versions, and to evaluate new packages, there's a highly-locked-down lab environment.
Sorry, but this reply is just ridiculous. There's more to being a developer than just writing a bunch of code in a flow state. And it's silly to claim you're so deep in "flow" that you can't be bothered to read and understand a security popup.
If that's how you work, then you're part of the problem.
Yes. If you "can't" read the security popup that very clearly tells you that this is a risky action and you should only do it if you trust the repo, then it's either a reading comprehension issue, and you should take remedial classes - or you're intentionally ignoring it, and so deeply antisocial and averse to working with other people.
Both of those things are extremely bad in any work environment and I would never hire someone displaying either of those traits.
I think it would be better to defer the Workspace trust popup and immediately open in restricted mode; maybe add an icon for it in the bottom info bar & have certain actions notify the user that they'd have to opt in before they'd work.
Because right now you are triggering the cookie banner reflex where a user just instinctively dismisses any warnings, because they want to get on with their work / prevent having their flow state broken.
There should also probably be some more context in the warning text on what a malicious repo could do, because clearly people don't understand why are you are asking if you trust the authors.
And while you're at it, maybe add some "virus scanner" that can read through the repo and flag malicious looking tasks & scripts to warn the user. This would be "AI" based so surely someone could even get a job promotion out of this for leading the initiative :)
Some JIT notification to enable it and/or a status bar/banner was considered, but ultimately this was chosen to improve the user experience. Instead of opening a folder, having it restricted and editing code being broken until you click some item in the status bar, it's asked up front.
It was a long time ago this was added (maybe 5 years?), but I think the reasoning there was that since our code competency is editing code, opening it should make that work well. The expectation is that most users should trust almost all their windows, it's an edge case for most developers to open and browse unfamiliar codebases that could contain such attacks. It also affects not just code editing but things like workspace settings so the editor could work radically different when you trust it.
You make a good point about the cookie banner reflex, but you don't need to use accept all on those either.
IMO this is a mistake, for basically the same reason you justify it with. Since most people just want the code to work, and the chances of any specific repo being malicious is low, especially when a lot of the repos you work with are trusted or semi-trusted, it easily becomes a learned behavior to just auto accept this.
Trust in code operates on a spectrum, not a binary. Different code bases have vastly different threat profiles, and this approach does close to nothing to accomodate for that.
In addition, code bases change over time, and full auditing is near impossible. Even if you manually audit the code, most code is constantly changing. You can pull an update from git, and the audited repo you trusted can be no longer trustworthy.
An up front binary and persistent, trust or don't trust model isn't a particularly good match match for either user behavior or the potential threats most users will face.
So why not allow for enabling this behavior as a configuration option? A big fat banner for most users (i.e. by default) and the few edge cases get the status bar entry after they asked for it.
I find this reply concerning. If its THE security feature, then why is "Trust" a glowing bright blue button in a popup that pop up at the startup forcing a decision. That makes no sense at all. Why not a banner with the option to enable those features when needed like Office tools have.
Also the two buttons have the subtexts of either "Browse folder in restricted mode" or "Trust folder and enable all features", that is quite steering and sounds almost like you cannot even edit code in the restricted mode.
"If you don't trust the authors of these files, we recommend to continue in restricted mode" also doesn't sound that criticial, does it?
>You're warned when you open a folder whether you trust the origin/authors with pretty strong wording.
I can see the exact message you're referring to in the linked article. It says "Code provides features that *may* automatically execute files in this folder." It keeps things ambiguous and comes off as one of the hundreds of legal CYA pop-ups that you see throughout your day. Its not clear that "Yes, I trust the authors" means "Go ahead and start executing shell scripts". Its also not clear what exactly the difference is between the two choices regarding how usable the IDE is if you say no.
"May" is the most correct word though, it's not guaranteed and VS Code (core) doesn't actually know if things will execute or not as a result of this due to extensions also depending on the feature. Running the "Manage Workspace Trust" command which is mentioned in the [docs being linked][0] to goes into more detail about what exactly is blocked, but we determined this is probably too much information and instead tried to distill it to simplify the decision. That single short sentence is essentially what workspace trust protects you from.
My hope has always been, but I know there are plenty of people that don't do this, is to think "huh, that sounds scary, maybe I should not trust it or understand more", not blinding say they trust.
[0]: https://code.visualstudio.com/docs/editing/workspaces/worksp...
Dunno how to break it to you but most of the people using AI the most, they are not very good at computers.
I think with AI we quickly progress to level where it needs to essentially run in nice lil isolated sandbox with underlying project (and definitely everything else around it) being entirely read only (in form on overlay FS or some similar solution), let it work in the sandbox and then have user only accept the result at end of the session in form of a separate process that applies the AI changes as set of commits (NOT commiting direct file changes back as then malicious code could say mess stuff up in .git dir like adding hooks). That way at very worst you're some commit reverts out in main repo.
AI certainly made everything in this area more complicated. I 100% agree about sandboxing and we have people investing in this right now, there's an early opt-in version we just landed recently in Insiders.
Interesting! Is there a pointer to an issue where this feature is described by chance?
Meet the new Microsoft - same as the old one. This is the same reasoning that led to a decade of mindnumbingly obvious exploits against Internet Explorer. You've got to create secure defaults. You have to ask whether your users really want or need some convenience that comes at the expense of an increased attack surface.
The grey bar at the top that says "this is an untrusted workspace" is really annoying & encourages users to trust all workspaces.
It's intentionally prominent as you're in a potentially very degraded experience. You can just click the x to hide it which is remembered the next time you open the folder. Not having this banner be really obvious would lead to frustrated users who accidentally/unknowingly ended up in this state and silly bug reports wasting everyone's time about language services and the like not working.
imo there's nothing "degraded" about editing text without arbitrary code execution. that's what text editors are supposed to do.
Visual Studio Code was announced from day one as a lightweight development environment, not as a "text editor".
Hi, I'm one of the researchers that identified this threat and I blogged about it back in November (https://opensourcemalware.com/blog/contagious-interview-vsco...)
First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.
The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:
1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.
2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about: "presentation": { "reveal": "never", "echo": false, "focus": false, "close": true, "panel": "dedicated", "showReuseMessage": false}
3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.
Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).
Just search github and you'll see what I mean: https://github.com/search?q=path%3Atasks.json+vercel.app&ref...
There are dozens and dozens of bad guys using this technique right now. Microsoft needs to step up. End of story.
We're planning on switching the default in 1.109 with https://github.com/microsoft/vscode/issues/287073
My main hesitation here was that really it's just a false sense of security though. Tasks is just one of the things this enables, and in the core codebase we are unable to determine what exactly it enables as extensions could do all sorts of things. At a certain point, it's really on the user to not dismiss the giant modal security warning that describes the core risk in the first sentence and say they trust things they don't actually trust.
I've also created these follow ups based on this thread:
- Revise workspace trust wording "Browse" https://github.com/microsoft/vscode/issues/289898 - Don't ask to enable workspace trust in system folders and temp directories https://github.com/microsoft/vscode/issues/289899
Oh wow that's the first time I've heard about those tasks. I would never consent to that and that they are enabled by default and shipped in the .vscode folder where most people probably nevereven would have thought about looking for malicious things that's kind of insane.
would it possible to show to alert only when there are potentials threats instead of every time a folder is open? Like showing a big red alert when opening a folder for the first time with a ".vscode" folder in it?
It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services. How could this threat detection possibly be complete? In this new LLM-assisted world a malicious repository could be as innocuous as a plain text prompt injection attack hidden in a markdown file, or some random command/script that seems like it could be legitimate. There are other mitigations in place and in progress to help with the LLM issue, but it's a hard problem.
This demonstrates the actual real-world problem, though. You're saying "this is a complex problem so I'm going to punt and depend on the user to resolve it". But in real life, the user doesn't even know as much as you do about how Code and its plugins interact with their environment. Knowledgewise, most users are not in a good position to evaluate the dangers. And even those who could understand the implications are concentrating on their goal of the moment and won't be thinking deeply about it.
You're relying the wrong people, and at the wrong time, for this to be very effective.
> It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services.
Which code? Its own Code (which the user already trusts anyway), or code from the workspace (automatically)? My expectation with a language-server is that it never code from the workspace in a way which could result in a side effect outside the server gaining understanding about the code. So this makes little sense?
Your expectation is wrong in this case for almost all languages. The design of Pylance (as is sorta forced by Python itself) chooses to execute Python to discover things like the Python version, and the Python startup process can run arbitrary code through mechanisms like sitecustomize.py or having a Python interpreter checked into the repo itself. To my knowledge, Go is one of the few ecosystems that treats it as a security failure to execute user-supplied code during analysis tasks, many languages have macros or dynamic features that basically require executing some amount of the code being analyzed.
Installing dependencies on folder open is a massive misfeature. I understand that you can't do anything about extensions that also do it but I really hope that you guys see how bad an idea that is for the core editor. "Do I trust the authors of this workspace" is a fundamentally different question than "can I run this code just by looking at it"
> It's perfectly fine to not trust the folder, you'll just enter restricted mode that will protect you and certain things will be degraded like language servers may not run, you don't be able to debug (executes code in vscode/launch.json), etc.
This is the main problem with that dialog: It’s completely unclear to me, as a user, what will and will not happen if I trust a workspace.
I treat the selection as meaning that I’m going to have nothing more than a basic text editor if I don’t trust the workspace. That’s fine for some situations, but eventually I want to do something with the code. Then my only options are to trust everything and open the possibility of something (?) bad happening, or not do any work at all. There’s no visibility into what’s happening, no indication of what might happen, just a vague warning that I’m now on my own with no guardrails or visibility. Good luck.
How about showing the user what the ide will automatically execute upon install?
My first reaction has been: when we install some node modules, import them and eventually run them, we do grant local execution permissions to whatever the authors of those modules coded in their scripts, right? More or less every language already suffer from the same problem. Who vets the code inside a Ruby gem, a Python package, etc? Add your favorite language.
However I did not know about tasks.json (I don't use VSC) and when I googled it I found the example at https://code.visualstudio.com/api/extension-guides/task-prov... and that is about running rake (Ruby.) So this is a little worse than installing malicious packages: the trigger is opening a malicious repository from the editor. Is this a common practice? If it is, it means two things: 1) the developer did not take an explicit choice of installing and running code, so even the possibility of an attack is unexpected and 2) it affects users of any language, even the ones that have secured package installation or have no installation of packages from remote.
You get asked if you trust the folder you’re opening every single time you open a new folder in VsCode. Everyone probably always just says yes but it’s not like it doesn’t tell you that opening untrusted folders is dangerous.
Until this post it wasn't clear to me that just opening and trusting a directory can cause code to be run without taking any other explicit actions that seem like they might involve running code, like running tests. My bad, but still!
reply to multiple comments :
mjdv : > it wasn't clear to me that just opening and trusting a directory
andy_ppp : >obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.
Understandably, there's a disconnect in the mental model of what "opening a folder" can mean in VSCode.
In 99% of other software, folders and directories are purely navigation and/or organization and then you must go the extra step of clicking on a particular file (e.g. ".exe", ".py", ".sh") to do something dangerous.
Furthermore, in classic Visual Studio, solutions+projects are files such as ".sln" and ".vcsproj" or a "CMakeLists.txt" file.
In contrast, VSCode projects can be the folders. Folders are not just purely navigation. So "VSCode opening a folder" can act like "MS Excel opening a .xlsm file" that might have a (dangerous) macro in it. Inside the VSCode folder may have a "tasks.json" with dangerous commands in it.
Once the mental model groks the idea that a "folder" can have a special semantic meaning of "project+tasks" in VSCode, the warning messages saying "Do you trust this folder?" make more sense.
VSCode uses "folders" instead of a top-level "file" as a semantic unit because it's more flexible for multiple languages.
To re-emphasize, Windows File Explorer or macOS Finder "opening a folder" do not run "tasks.json" so it is not the same behavior as VSCode opening a folder.
Oh man! Microsoft was the #1 company with this problem for over 25 years and they still do it?
Word and Excel “MACROS” used to be THE main vector for kiddie viruses. Come on M$ … billions of dollars and you’re still loading up non-interactive code execution in all your documents that people expect to be POD (Plain Old Data)?
https://support.microsoft.com/en-us/office/protect-yourself-...
Is it so much to ask for your software to AT LEAST warn peole when it’s about to take a destructive action, and keep asking until the user allows that class of thing non-interactivlely ONLY FOR THAT SIGNED SOFTWARE?
Apple does other software things really badly with their millions of dollars, but they get Privacy RIGHT: https://www.youtube.com/watch?v=XPogdNafgic
VS Code does exactly that, warns before loading this non-interactive code. It warns you loudly, with an ugly modal dialog, on opening a new to it folder and suggests Restricted Mode. A lot of the arguments here relate to:
1) This loud warning is easy to ignore, despite how loud it is
2) This loud warning is easy to disable, which many desire to do because it is very loud
3) This loud warning is easy to build bad habits (instead of marking safe parent folders, continually clicking Allow and training yourself to only click Allow)
4) Restricted Mode sounds "too restricted" to be useful (though it isn't too restrictive and is very useful)
5) Restricted Mode is also loud to remind you that you are in it, so many users think it is too loud and never want to be in it (despite it being very useful)
No, not loading code. Executing dangerous actions. There is a huge difference. Watch the video I had linked to!
Maybe I'm confused at what you mean, but I don't think there's a huge difference. Loading code is a dangerous action. VS Code is doing exactly what the video is talking about: it gives you a big popup window before doing a dangerous action (that could violate your privacy, that could be malware, that could do things you don't expect).
We want to load code in Turing complete languages. We want complex build tools and test harnesses to load "just so", and those too are generally Turing complete and configured and written in Turing complete languages. Parsing code in a Turing complete language takes another Turing complete language, generally. (Most languages are self-hosted so parsing the code is an action in that same language.)
One of the most dangerous actions we know of is an ancient and inescapable "bug" in all Turing complete work: the Halting Problem. We cannot mathematically prove any program will complete nor when it will complete, without running it and waiting for it to complete, if it completes. Infinite loops are both the power granted to us by our tools and the potential downfall of them all, our responsibility to deal with them is in our hands and math can't help us enough.
Loading code is a dangerous action. VS Code is doing the right thing in how it is handling it. It's not the best user experience and clearly not enough users understand the dangers inherent in "do you really want to run all your extensions in this folder?" in precisely the same way that people better understand "Do you want this application to have access to your precise location?" is a threat (that apps do take advantage; in both cases).
Code is instructions
Some instructions are benign, eg to add two numbers or even divide by zero
Other instructions call APIs of the OS
It is at these times that the user should be prompted interactively whether they want the action to be done, with full details of what the scope is, and keep asking every time until the user checks a box that says “continue allowing this action on this scope to THIS program”.
I think I see what you are asking: why isn't it more granular?
In VS Code the granular options exist, too. Restricted Mode is just a pseudo-profile with (almost) no Extensions loaded and a couple other settings disabled. You can use the VS Code profiles and workspace controls to set many other granular in-between states.
I think where the fundamental disagreement I have with your perspective lies, and it is sort of the decades-long "lesson of Windows and Office" (which I'll circle back to) and also one of the deepest, oldest theoretical concerns of Computer Science, is that there is unfortunately no such thing as "benign code". The Halting Problem and its corollary the "Zero-Day Sandbox Exploit in the Universal Turing Machine" suggest that mathematically we have no real tools to determine what is actually benign versus what looks benign.
If you don't like the math theory side of that argument, then we can absolutely discuss the practical, too. We can start with the example you have given that even divide by zero can be benign. That's a pretty good example. We've designed computers so they don't halt and catch fire on a divide by zero, sure, but to do that we have things like stateful error registers and even processor interrupts to jump immediately to different code when a divide by zero happens. Other code could be relying on those error registers as well and may get to its own unexpected state. Interrupts and jumps can be taken advantage of to run code the original program never expected to run.
Little processor-level details like that add up and you get giant messes like SPECTRE/MELTDOWN.
That's also just one low level place to inject malware, you can do it in any programming language anywhere in the stack. This is where VS Code is especially in such an unenviable position because it wants to be a development environment for all possible programming languages so has just about no idea what the full breadth of the stack of programming languages you've configured to want to run in the Extensions that you've installed and the CLI tasks it can automate. VS Code isn't your Operating System (it is not yet trying to be that much like Emacs), it doesn't sandbox your Extensions, it doesn't limit what APIs the CLI build tools you have installed can run.
There are practical exploits of this directly in the article here. More can be found with easy searching. Granularity only helps so much. A big general, loud warning isn't the best experience, but its the closest to the safest option available to VS Code (not just because it isn't your OS, and also OSes are omniscient).
The safest option for VS Code really is "Don't autostart anything, it might be dangerous". Just as Windows has had to stop autorunning JScript and VBScript (once considered "benign"). Just as Windows has had to stop autorunning AUTOEXEC.INI instructions when a CD or USB disk is inserted (once considered "benign"). Just as Office has had to stop running VBA macros on startup (once considered benign). I wish VS Code took a couple more steps towards the Excel experience ("Protected Mode" sounds kinder than "Restricted Mode", it's a subtle difference, but subtle differences matter; fewer flow-interrupting modals and more "quietly default to Protected Mode"), but the general principle here isn't in question in my mind.
But going back to this is also deeply and disturbingly tied back to some of the oldest theories and questions of Computer Science, it also seems useful to remind everyone that if you want to feel truly paranoid, the only safe way to use a computer is to never use a computer. We don't know how to differentiate benign code from dangerous code, we likely never will. Not your OS, not your code editor, not even your abstract Universal Turing Machine you are running with pencil and paper. Unless we find some sort of left-field solution to the Halting Problem, we're kind of stuck with "Computers are inherently dangerous, proceed with caution".
The message displayed when asking if you want to trust the directory is pretty clear about it.
https://code.visualstudio.com/docs/editing/workspaces/worksp...
I don't like the way it is handled. Imagine Excel actively prompting you with a pop up every time you open a sheet: "Do you trust the authors of this file? If not you will loose out on cool features and the sheet runs in restricted mode"
No it doesn't because restricted mode without Macros is the default and not framed like something bad or loosing out on all of those nice features,
I think Excel does do something similar though with Protected View. https://support.microsoft.com/en-us/office/what-is-protected...
Exactly that's why I was making the comparison, It's not a in your face PopUp, where users get used to just pressing the blue, highlighted and glowing "I trust the authors" button without even being told what features they'd miss out on.
The Protected view in Office instead tells you "Be careful" and to only activate editing when you need to.
It's also worth noting that this behavior evolved very slowly. It took Excel decades to learn how to best handle the defaults. Excel started with modals similar to VS Code's "Do you want to allow macros? This may be dangerous", found too many users self-trained on "Allow" as the only button that needed to be pressed and eventually built the current solution.
If VS Code is still on the same learning curve, hopefully it speeds up a bit.
Right, I think one of the biggest problems is the name "Restricted Mode" itself. It sounds like a punishment, when it is a safer sandbox. Restricted Mode is great and incredibly useful. But it is unsurprising how people don't like to be in Restricted Mode when it sounds like a doghouse out back, not a lobby or atrium on the way to the rest of the building.
The point of an IDE is that it does stuff a simple text editor does not.
Sure, but as noted elsewhere, the IDEs generally don't "do stuff" by default just on opening a file folder. VSCode, by default, will run some programs as soon as you open a folder.
> the IDEs generally don't "do stuff" by default just on opening a file folder
In any JetBrains IDE: Settings > Tools > Startup Tasks.
It's worded really badly, so vscode is the thing that provides the dangerous features? No problem, I know and trust vscode. What the message should be warning about is that the folder may contain dangerous code or configuration values that can execute upon opening due to vscode features that are enabled by default. That sounds worse for them but that would be honest.
But you, as a security conscious software developer, know that the phrase "may automatically execute files" can also be "with malicious intent" - the tradeoff that whoever made the text (and since it's open source it's likely been a committee talking about it for ages) had to make is conciseness vs clarity. Give people too much text and they zone out, especially if their objective is "do this take home exercise to get a job" instead of "open this project carefully to see if there's any security issues in it".
This problem goes back to uh... Windows Vista. Its predecessors made all users an admin, Vista added a security layer so that any more dangerous tasks required you to confirm. But they went overboard and did it for anything like changing your desktop background image, and very quickly people got numb to the notice and just hit 'ok' on everything.
Anyway. In this particular case, VS Code can be more granular and only show a popup when the user tries to run a task saying something like "By permitting this script to run you agree that it can do anything, this can be dangerous, before continuing I'm going to open this file so you can review what it's about to do" or whatever.
The message, at least for me, does not convey that merely opening may lead to code execution.
Other IDEs do this too btw
Really? "May automatically execute files" suggests to me that at least code could execute without me taking any further explicit action.
What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.
Here are some examples:
- ESLint, the most commonly used linter in the JavaScript ecosystem uses a JavaScript file for configuration (eslint.config.mjs), so if you open a JS project and want your editor to show you warnings from the linter, an extension needs to run that JS
- In Elixir, project configuration is written in code (mix.exs), so if you open an Elixir project and want the language server to provide you with hints (errors, warnings and such), the language server needs to execute that code to get the project configuration. More generally it will probably want to expand macros in the project, which is also code execution.
- For many languages in general, in order to analyze code, editor extensions need to build the project, and this often results in code execution (like through macros or build scripts like build.rs, which I believe rust-analyzer executes)
Thanks! I think it would be better if these types of events were fine grained and you could decide if you wanted to run them the first time but I can understand them being enabled now.
More granular is more likely to train users on "Always Click Allow". The current modal dialog already has that problem and is just one O(N) dialog where N is the number of folders you open (modulo opt-outs). If you got O(N * M) of these where N is the number of folders and M is the number of tasks in tasks.json plus the number of Extensions installed that want to activate in the folder, a) you would probably go a little batty), and b) you would probably stop reading them quickly and just always click Allow.
(It can also be pointed out that a lot of these are granular under the hood. In addition to Restricted Mode as a generally available sandbox, you have all sorts of workspace level controls over tasks.json and the Extensions you have installed and active for that workspace. Not to mention a robust multi-profile system where you can narrow Extensions to specific roles and moods. But most of us tend to want to fall into habits of having a "kitchen sink" profile with everything always available and don't want to think about granular security controls.)
When you open up a folder in VS code, addons can start to set up language servers to index the code in the folder. This usually involves invoking build systems to set those up.
(I think some people are fixating on the specific feature that's mentioned in the article. The reason this pop-up exists is that there are many ways that this code execution could happen. Disabling this one feature doesn't make it safe, and this feature if not present, could still be achieved by abusing other capabilities that exist in the vs code ecosystem)
Makefiles etc. Many types of projects use arbitrary setup and build commands or can load arbitrary plugins, and unlike VS which imposes its own project format, VSC tries to be compatible with everything that people already use. Git hooks are another one.
Please see the reply to the other comment, obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.
Some project types, such as Gradle or Maven projects, use arbitrary commands or plugins in project setup. You have to run arbitrary plugins to know which directories are the source directories, and you have to know which directories are the source directories to do anything in Java.
There’s no need to run that when opening a directory is there?
If you just want to see the files in the directory, then sure. But VS Code is an IDE. It's made for editing software projects which have more structure than that.
Programming projects frequently feature scripts for building and packaging said projects, those have to be run somehow.
Bundling running those into the editor seems like the mad part to me, but I've missed the whole VSCode train so probably something I'm missing.
The grand parent is talking about code execution can happen by just opening the directory, you’re imagining like I did (and the grandparent) that you have to run or execute something in VSC to get that to happen and I’m asking about what features could possibly require this to happen. Obviously running tests or a make file everyone understands clearly you’re executing other people’s code.
It’s not even running tests. Test extensions usually have to run something to even populate the tests panel in my first place and provide the ability to run à la carte. Thus opening a folder will cause the test collector binary to run.
They could ask and/or parse the tests for the information rather than run them to output it. I’m honestly still not seeing a killer feature here that makes the security implications worth it!
The trouble is that "just parse the tests" isn't always an option and running arbitrary code is the nature of how software is built.
The easiest example is JS testing. Most test harnesses use a JS file for configuration. If you don't know how the harness is configured how do you know you are parsing the right tests?
Most test frameworks in JS use the define/it `define("some test colection", () => it("some test", () => /* …test code… */))` pattern. Tests are built as callbacks to functions.
In theory, sure, you could "just" try to RegEx out the `define("name"` and `it("name"` patterns, but it becomes harder to track nesting than you think it is with just RegEx. Then you realize that because those are code callbacks, no one is stopped from building meta-test suites with things like `for (thing of someTextMatrix) { it(`handles ${thing}`, () => /* …parametric test on thing… */ }`.
The test language used most in JS is JS. It's a lot harder problem than "just parsing" to figure out. In most cases a test harness needs to run the JS files to collect the full information about the test suite. Being JS files they are Turing Complete and open to doing whatever they want. Many times the test harnesses are running in a full Node environment with access to the entire filesystem and more.
Most of that applies to other test harnesses in other languages as well. To get the full suite of possible tests you need to be able to build that language and run it. How much of a sandbox that language has in that case shifts, but often it is still a sandbox with ways to escape. (We've proven that there's an escape Zero Day in the Universal Turing Machine, escapes are in some ways inevitable in any and all Turing Complete languages.)
yeah me as well. at least have the untrusted code allow certain plugins or certain features of plugins to run that you whitelist. not having vim keybindings or syntax highlighting is too barebones.
The message isn't very clear on what exactly is allowed to happen. Just intuitively, I wouldn't have expected simply opening a folder would "automatically execute tasks" because that's strange to me
https://code.visualstudio.com/docs/editing/workspaces/worksp...
It is very clear, the first sentence it that it may automatically execute code.
>Code provides features that may automatically execute files...
What features? What files? "may"? So will it actually happen or is it just "well it possibly could"?
I've used it to open folders that I personally made and which don't have any tasks or files that get automatically executed, and yet the message pops up anyway.
It's like having an antivirus program that unconditionally flags every file as "this file may contain a virus"
> What features? What files? "may"? So will it actually happen or is it just "well it possibly could"?
How is code supposed to know? It probably depends on the plugins you installed.
> It's like having an antivirus program that unconditionally flags every file as "this file may contain a virus"
No, it’s like if your OS asks if you want to actually run the program you’re about to before running it the first time. And it gives you the alternative to run it in a sandbox (which is equivalent to what happens when you don’t trust the workspace, then it still opens but in restricted mode)
Yeah, because there are a lot of mechanisms by which a folder may start to execute code when you open it outside of restricted mode. A large fraction of addons have something which could be used for this, for example. There isn't a general check that it can apply ahead of time for this.
(They could, with some breaking changes, maybe try to enforce a permissions system for the matrix of addons and folders, where it would ask for permission when an addon does actually try to run something, but this would result in a lot of permission requests for most repos)
They could also, with a breaking change, enforce addons register what sorts of files they'll execute when a folder is opened in trusted mode. If no matching files are found, then opening the folder is safe and no prompt is needed. If matching files are found, then prompt the user and replace "may" with "will". Fewer permission requests, and a clearer message.
People will still inevitably ignore the message and open everything in trusted mode, but it'd be more reasonable to consider that user error.
Thing is, when you open a webpage it's clear that it may automatically execute code (Javascript, WebAssembly). What needs to be clear (and by default limited) is the authority of that code.
This is when I say no.
Then copy-paste my default .dev-container directory and reload.
autorun.inf flashbacks.
I’ve always defaulted to no.
On Debian I actually get a surprising amount of packages from just the official repo. In Python or R, I could almost do a full analysis just with those packages. The smaller number of separately installed packages, I can at least do a superficial sanity check. An alternative model of doing things exists. Considering how infinitesimally small Debian is compared to Windows and MacOS, if we had more users, momentum, and volunteers, I have no doubt that I could do everything with well-tested packages only.
The reason it's worse in the js ecosystem is that you need way more packages than your average language to build anything functional.
You don't really need more packages. There's definitely a culture of creating ridiculously small packages, though.
If you spend enough time in the ecosystem, you'll begin to realise that a select few are very well known for doing this; one in particular made a package for every ANSI terminal colour.
left-pad (and quite a few incidents afterwards) were definitely wakeup calls, and I like to think we've listened in some ways.
I do feel like better application sandboxing is needed but so much open source software is built on the Unix abstraction meaning you have to run in a container, but macOS doesn’t have containers as far as I can see, and containers themselves are a bit of a poor abstraction, although maybe the best we can do with Unix at the core. I think something closer to Roblox studio would be cool where when you open an environment stuff just spins up in the background, but there is a good debugger, logging, developer ide, good rendering, eg 3d graphics, separate projects are separate, and when you spin down a game (read app or project) everything spins down.
Apple did actually introduce its own container framework in Tahoe, but it’s still early days. https://github.com/apple/container
These are Linux containers in a VM, I’m pretty sure GP is talking about native macOS containers.
Which: They do actually have some container-like sandboxing tech around applications (“iTerm wants to access your downloads folder”).
Yes, afaik macOS apps could theoretically be sandboxed as well (or close to) as iOS apps are. You can find the policies for many first-party apps and deamons in /System/Library/Sandbox/Profiles. But in practice most third-party apps aren't.
https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-poli... and https://bdash.net.nz/posts/sandboxing-on-macos/ are good introductory articles.
It's a good idea so it can't take over your dev machine.
But not sufficient since it'll still F over whatever code you are working on resulting in a backdoored app getting deployed + infected dev scripts etc bringing interesting times to your teammates, downstream open source project users, your api keys and cloud credentials getting compromised etc.
I don't think it's viable to containerize an IDE. Running user code at full permissions is a core feature for an IDE. The programs that the user develops in an IDE could potentially touch any OS surface. When the user is a developer, you have to trust them.
Though this autorun feature is crazy and should be completely off by default.
apple has pretty good containers actually. why do you say they are a poor abstraction?
UTM is free and spins up native macOS VMs. If I absolutely have to write JavaScript that’s where I do it, since Sha1 Hulud.
That what stuff like XPC and entitlements are for, which naturally programs from UNIX culture background don't care to use.
[dead]
It's Macro-enabled Office files all over again.
autorun.inf
Next up: Javascript virtual operating systems.
Deeper: "Replacing my OS process scheduler with an LLM"
https://news.ycombinator.com/item?id=46435142
That's essentially what WASM does, no?
we need to go deeper
In VS Code settings search for "tasks" you will find "Task: Allow Automatic Tasks"...turn it off.
Anything else that should be locked down?
Don't mark the folder as trusted when you open in VsCode. The number of other hooks that may exist is going to be hard to track down (especially because each addon may add their own).
This may only provide a flalse sense of security. Afaik, there is no way to disable workspace settings taking priority over user settings, so a malious repo can easily override them and reenable automatic tasks.
Various settings are `restricted` in the codebase to only use them when the workspace is trusted. `allowAutomaticTasks` is one such setting: https://github.com/microsoft/vscode/blob/f7730c409e14af94d75...
So a malicious repo can easily override it... if you say you trust it.
Sounds like autorun on usb drives all over again. They cant learn
I think that's a bit ungenerous: there is a push and pull between security and seamless user experience and it's never obvious where the line should be set. You really only figure out which way to move it after someone complains.
Even if you lock everything now, what if the thing autoupdates with new helpful "features". You can't patch bad development culture.
1. Uninstall VSCode
2. Install Vim / Emacs / Sublime / Helix
3. ????
4. Profit
> Helix
I'm not sure about the other ones, but I know that helix supports language servers by default and it does not have a workspace trust system like vscode, so LSPs can automatically execute code when you enter a directory
https://github.com/helix-editor/helix/issues/9514#issuecomme...
So uninstalling VSCode would be a bit of a step back in that case
Yes, uninstall the whole thing. It's just a Chromium covered with a bunch of JavaScript.
Coming from the perspective of an eclipse fan, why is VS code the defacto answer nowadays?
Im forced to use vs code (so biased), but everything seems worse than eclipse, plus these repeated security issues from malware laced projects.
Theres been several posts about infected projects by fake recruiters here in the last year or two.
Im guessing the answer is probably Java is why eclipse is out of favor.
> Coming from the perspective of an eclipse fan, why is VS code the defacto answer nowadays?
Is eclipse good now? I used it 15 years ago. It took ages to start. It was a memory hog and it was dog slow besides. My entire team got RAM upgrades on our computers because the default company issued machines (which were quite good at the time) didn't have enough RAM to use eclipse properly.
I can't imagine why it went out of favour...
This is exactly what I was going to say. I used eclipse in college when learning Java. Back then it was bloated, slow, had really bad UX, and would occasionally crash for no reason I could ascertain (I was just doing basic school projects. Linked lists, binary search trees, etc...)
VS Code, although it is starting to go get a bit bloated, has always been extremely responsive and snappy. Yeah I've had it crash, but I was never surprised that it crashed. (e.g. opening enormous files, running several instances at once with tons of tabs open, long debugging sessions, etc...)
But now I use NeoVim so none of that matters...
Definitely, it has been at least a decade since I had plugins corrupt my workspace, and there are old Reddit comments of me complaining about in on /r/java.
Load VSCode with the same amount of plugins, each requiring its own process, to see how "fast" it runs, not to mention Electron crap, there is a reason so many Microsoft plugins are actually written in C++ and Rust.
> It took ages to start. It was a memory hog and it was dog slow besides. My entire team got RAM upgrades
The more things change, the more they stay the same. I used to use VS Code on some very large C projects with 16GB of RAM, and my machine would grind to a halt while intellisense was indexing.
The indexer was probably clangd, not Code itself.
IME more likely cpptools (which comes with vscode) than clangd.
Relevant: https://news.ycombinator.com/item?id=43788332
That's correct. Clangd doesn't churn nearly as hard as cpptools, but it's also not nearly as good as cpptools.
How much ram did you have, and when was this? I remember being extremely happy with Eclipse on an 8GB machine - this was back in the jvm7 days. Heck, I did jvm6 development with Eclipse on Windows XP with 4GB of ram and was content.
Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.
For years and years I had people telling me how great IntelliJ was, etc. I eventually switched - lo and behold, IntelliJ had just as many quirks (even some of the same) as Eclipse.
It was 2010. Our default work machines had 16gb of ram. Eclipse ran, but it was tight. Especially while debugging. Some developers also apparently liked to open a second eclipse instance for some reason. You'd go OOM pulling stunts like that.
They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE.
In eclipse's defence, we were working on a very large java codebase. But that shouldn't have been a surprise to anyone. I've never seen a java codebase come in any other size.
I'm running intellij (RustRover) right now, and its sitting on about 4.5gb of ram. That still seems very inefficient to me. But it doesn't sound that bad compared to eclipse.
16gb. Ram in 2010?! That's like top 10%, not standard. Even now computers are shipping with 16/32gb ram
At this time laptops still could have memory upgrades, and memory was pretty cheap compared to today. The first thing I did when I bought a new laptop was buying two 8GB SoDIMMs, it was way cheaper than ordering the upgrade from factory.
The thing is, memory in personal computer have plateaued for quite some time. 16GB was not uncommon in 2010. Things are not like the crazy 90s and early 2000s where PC configuration become obsolete in less than two years.
That seems incredible. 16GB of ram to run (presumably windows 10) and Eclipse?
Eclipse, unlike IntelliJ offers "project" view were you have have many "solutions" open at once. Even with multiple Eclipse instances open, it's hard to imagine it consuming so much ram.
Perhaps you had other company-required software running. I was working on relatively largeish codebases and very happy with 8GB of ram until 2018ish.
Regardless, an IDE is more than a text editor, so your claim that RustRover with 4.5GB of ram is inefficient is misguided.
> That seems incredible. 16GB of ram to run (presumably windows 10) and Eclipse?
In 2010 it couldn't have been anything later than Win 7; Win 8 was released in 2012.
>They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE.
With the current prices it is still wild mate.
Funny thing, memory was cheaper, and machines were upgradeable. People used to buy low memory machines and upgrade them with after market memory to avoid paying DELL or Apple's memory upgrade tax.
> Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.
More like Eclipse struggled on the kind of hardware that people could afford as a student.
My main memories of Eclipse (15 years ago at this point) are waiting forever for it to start up, though it was pretty adequate after that.
Right, but it’s essentially a fancy text editing environment. It should never have needed anything but barebones hardware.
> essentially a fancy text editing environment
No, it’s an IDE first. Not a text editor that’s extensible. It has a lot of features built-in, pre-enabled, and configured out of the box.
Yes, it can edit text. But it can do a lot more.
And it clearly violated the "only pay for what you use" philosophy. Like driving a bulldozer to get a soda.
Until you actually do any of those things, an IDE is a fancy text editor.
and a 747 is a nice bed until you fly it. Doesn't mean it's overkill and a plane.
That's an absurd comparison, and you know it. Until an IDE actually performs some task that requires more advanced functionality, like analyzing a complex existing project to open without anything cached, compiling, profiling, etc. it is literally just editing text files. The only IDE that I use that takes anywhere CLOSE to the amount of time that Eclipse does to get moving is Unreal Engine. Any Jetbrains IDE, X Code, Visual Studio... all blow it away. I just opened a project in Visual Studio 2022 on a portability-focused laptop from 2018-- from click to the project open screen, it was about 3 seconds. From the project open screen to having an existing project completely open, it was 3 or so more seconds. On an 8 year old, tiny, not-optimized windows laptop.
I remember the first thing you had to do with eclipse was increase the memory limit so the obese hog called JVM could have barely enough room to wiggle around.
> Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.
My first IDE was Turbo Pascal 2.0, about 20 years before I used Eclipse, and I used a lot in between (and since). Eclipse was the single most unintuitive, user hostile, clunky, slow, and painful system to use. A few of those problems probably would have been a little bit less noticeable on a ridiculously high-end machine, but not all of them, and other contemporary IDEs worked well-enough on lighter machines. And despite how much I disliked using Eclipse, I liked the idea of Eclipse, and kept it around because it was, for a while, occupying the niche of “extensible open source platform most popular to target for interesting dev tools” (because there weren't really any alternatives that were as open and extensible).
I used eclipse in university around that time (2005), then first switched to netbeans which I already liked more, then discovered IntelliJ and have been using that ever since. Everything about Eclipse felt worse in ways neither of the others did, but all of that was still during university (though I now use JetBrains professionally).
> Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.
this is a huge assumption and also ignores the fact that if it's not clear to users, it's a bad design.
yes, 15 years ago 8GB was normal on notebook. We though started to use it in the early naughts on 256Mb.
>Heck, I did jvm6 development with Eclipse on Windows XP with 4GB of ram and was content.
of course :)
Todays hard drives are faster then memory was back then, so it's probably not an issue now. Could probably reparse your entire code base at every key stroke without you noticing.
Modern PCIe NVME drives typically see a few microsecond latency, but even DDR2 latency was around 10 nanoseconds. Memory remains top dog by a long shot.
We used to have a custom Eclipse-derived tool for embedded development, and it sucked. Poor performance, crashy, difficult to build and debug. VS code is just lighter. As well as feeling more "modern", simply due to being built with the prejudices of the mid-2010s rather than the late 90s. Eclipse 1.0 was in 2001!
I switched to VSCode because it has a free editor with a really great jump to file hotkey.
I remember when the big VS added jump to file but it was so damn miserably implemented as to be useless.
Having worked at Microsoft for a decade, the most frequent way I navigated a large source tree was dir /s *partialfilename*.*
Then again while I was there, most code bases couldn't even open in Visual Studio. (highly team dependent, I was mostly on older C/C++ code bases.)
Some teams at MS paid for an editor called Source Insight, which indexed your code and could also parse C #defines and other preprocessor macros, which was super unique and powerful. It had an incredibly powerful symbol and fuzzy filename search capabilities, I'd frequently have Source Insight open just so I could find where in a folder structure a file was and then I'd open it up in my preferred editor.
Back when I got my first SSD the largest boost to my dev productivity was not in compile times (large C++ code bases tend to template bound more so than IO bound), it was how fast I could find files in the directory structure.
I'm sure Vi/Emacs users have some magic set of plugins that do all of this for them, but as someone back on Windows back in the 2000s and 2010s, the supported MS tooling was horrible at all this.
Then VS Code comes along with amazing fuzzy file name matching. Holy cow. Sure it is missing 90% of the power of real Visual Studio (being able to have a debugger step from front end web code to your backend and then into stored procedures in SQL, running on a remote machine, that your debugger transparently auth'd to, is something Microsoft had working 20 years ago and would be considered impossible dark magic with today's tooling), but wow can I navigate a project quickly!
Site license to source insight was something I missed badly after Microsoft. Bought my own copy. It did wonders when looking at Snowflake monorepo, which was otherwise impossible to understand . Great piece of software, still going strong too.
Same here! Easily jumping between files is one of the best features. I always have VS and vscode open simultaneously, doing about 99% of the work in vscode and only using VS to compile and to debug.
Eclipse is not safer it just has fewer people looking for holes in it. The problem is not the software but how we trust code from the internet. Even if you used Eclipse a fake recruiter could still trick you into running a bad script. We cannot fix social engineering by changing the text editor.
For me vscode is super-lightweight and at the same time has enough functionality. I didn't use Eclipse for many years, but from my memory it was super-heavyweight. And it didn't really support anything except Java.
Interestingly Java is the only language that I've found vscode support poor, so I keep buying Idea license exclusively for Java projects. For rest of languages that I use (JS/TS, Go, Python, Shell, YAML, XML) I'm using vscode and happy about it.
In recent years vscode starting to get bloated, mostly with AI stuff. But so far I can disable everything AI with a single setting and it works good afterwards. I'd prefer for all AI features to be contained in a separate plugin that I can just not install, but I guess managers these days want to shove AI in everyone's throat.
Another good thing about vscode is that its written with JavaScript and can be launched in browser, so in the future I want to put my development environment in the browser, but so far I didn't do that.
why is VS code the defacto answer nowaday?
Personally, I don't use it because it's so dog slow.> A million plug-ins
> I don't use it because it's so dog slow.
You might find it runs better with fewer plugins.
Or with most language specific extensions disabled by default.
I almost disable all extensions except the ones I use all the time. Then I enable specific ones at workspace level.
Yes, it's annoying. But as an extension author, I know how some badly written extension can significantly slow down the experience, both during startup and editing. I even profiled other people's extensions and submitted feedback.
Load time is in seconds, even with the program cached. I can still load vim with a ton of plugins[0] and still load a project in a few hundred milliseconds.
Maybe VS Code is faster with fewer plugins but it's still "dog slow" to load and run. Only thing I'm "missing" in vim is the bloat
[0] personal I only use a handful but I've played around because why not
With LazyVim (requires NeoVim) and its load-on-demand architecture, startup time usually stays below 50 milliseconds even with a ton of plugins. Below 50ms is fast enough that it feels instant. Aliasing `nvim` to `n` in my ~/.bash_aliases just makes it even faster. cd to a project directory, run `n .` and I'm looking at the NeoVim file explorer plugin for that project directory. No break in thought flow, no standing up to get coffee while the IDE loads, just keep going.
Your focus on startup speed feels really alien to me. When working on a project I just keep vscode open. I reboot maybe once a week and starting vscode again takes about a second, and then maybe 10s of seconds of background processing, depending on the project size, for the language server to become fully operational. That's more than good enough for me.
I've done a lot of shell-driven development in the 00s though, and I remember it did involve frequently firing up vim instances for editing just a single file. I no longer understand the appeal of that approach. Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
I don't reboot often and I'm still lazy and will leave projects open often, but honestly, have you considered that your workflow is an adaptation to the wait time?
I agree? But why do you think people don't fuzzy search in vim? Or the terminal? There's been tools to do this for a very long time. Fzf is over a decade old and wasn't the firstIf you're using vim as an IDE (which is if course perfectly doable), then why does it matter if startup time is 50 or 1000 ms. You typically leave them running.
> Yet I'm doing the same thing instantly or near instantly.
Does vim somehow allow LSP servers to index faster? Or are you not actually doing the same thing?
Why are you leaving them running? Because they are slow to load?
Yes, Neovim supports LSP and it is very very fast.
I'm not sure why any of this is surprising. We're talking about the same company who is speeding up their file browser by loading it at boot time rather than actually trying to fix the actual fucking problems. Why is it surprising that everything else they make is slow and bloated as shit (even more as they've shoving AI into everything)
https://neovim.io/doc/user/lsp.html
The point of LSP is that neovim is using the same servers for this as vscode. So I guess you work on smaller projects or with languages that have faster (usually meaning less fully featured) LSP servers.
LazyVim includes a bunch of pre-configured plugins that turn NeoVim into an IDE. Fuzzy search by filename, search by text, file explorer, go to definition, go to reference... Even debugging and unit test runners, it's all there. Yet when I'm at the command line and I need to make a quick edit to one file, e.g. `nvim ~/.bashrc`, I don't pay the startup cost of waiting for 50 plugins I'm not going to use. So it's the best of both worlds.
To be honest I was giving myself some leeway. I'm pretty sure I'm loading in well below 100ms. It feels instant
>>Load time is in seconds, even with the program cached.
Are you like, for real? How often do you load it up for it to matter in the slightest? Do you not just open the project once at the start of the day and then continue working?
Sorry but for someone used to working in VS proper and projects which take minimum 40 minutes to build, saying that a startup time of a few seconds is a problem is.....just hard to understand.
I live in the terminal and opening files with vim is the primary way I interact with them.
I mean I do this too This sounds problematic and a whole different category of problems.Don't you have partial compiles? Parallel compiling? Upgrade your machine?
But it's not just startup time. I use less RAM, less CPU resources, jumping through tags is instant, working through the debugger is instant, opening new files is instant, fuzzy searching my system is instant. It sounds like the program you're working on and your editor are fighting for resources and I've never faced that problem with vim
>>Don't you have partial compiles? Parallel compiling?
We do. Without it it it takes over 3 hours for a full project build. Normally if I change one line of code and hit "run" it takes ~10-15 minutes for the app to start, depending on which file I changed.
>>Upgrade your machine?
It's a 64 core/128 thread core Threadripper workstation with 256GB of ram, so not many upgrade options from that.
It's a huge C++ project, heavily templated, that's kinda normal. My previous 2 projects were also like this.
Okay so in your unique situation I'll agree that the load times and resource consumption isn't meaningful if you agree your situation is not the norm
Lol this isn't unique nor out of the norm - most big C++ projects are like this, and certainly every one in my industry(video games), unless you're trying to make an argument that C++ is somehow not commonly used. I even worked on a small indie game in C++ and it took 5 minutes minimum to compile.
C++ is common, but game programming definitely isn't the norm.
And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant
I've also worked on systems which are entirely written with template metaprogramming. This is definitely not the norm. Though that code was highly focused on optimization, as we were writing for HPC environments (extremely heterogeneous hardware). Sure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane. A partial compile of a few minutes usually meant my time was better spent mucking about with the cmake and build files because incremental testing sped up development and your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.
>>C++ is common, but game programming definitely isn't the norm.
I mean, last time I checked there are hundreds of thousands of programmers working in this industry, and video games are a bigger industry than movies. What's not the norm about it, exactly? I imagine there's more programmers out there making video games than making accounting software, for example.
>>And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant
I'm sorry, I'm confused. Did I ever imply otherwise? Maybe let me say it again, clearer - so far I worked at 2 big AAA studios, on 5 big AAA franchises, in 4 different engines. All 5 of those had those multi-hour compilation times unless you used something like Incredibuild or Fastbuild, and every single one of them had a startup of around 10+ minutes if you made any change to the code at all, just for VS to finish compilation and linking. I also worked at a small indie studio, with its own C++ engine, we had maybe...200 files max? That project took 5 minutes to build. Don't know where you got the idea that I'm saying factor of 8 is insignificant.
>> your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.
Hmm at the current project the time from me submitting a change to it actually being accepted is ~6 hours. On my previous projects I think the fastest I've seen has been around an hour for a very very quick preflight. But then all the tests also have to pass which takes a lot of time.
>>ure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane.
Right, but you have to do this at least once when you get latest, normally in the morning I grab latest and have to build around ~9000 files. If I make a change in the gameplay code it might have to recompile ~200-300 files because of the dependencies on all the associated systems.
I have noticed that Antigravity is lightening fast, wonder what magic they are using?
Seems very odd to me that someplace would force the use of a particular development tool. I've seen it only one time while interviewing, where they wanted everyone to have identical setups so they could easily hop onto each others computers when needed... it was weird and I took it as a red flag and didn't follow through them them.
Some software development workflows require specific tooling, with complex setups. While it may be possible to do with other tools, it's often very difficult, and not really worth the trouble when there is a known working setup. It's easier to onboard new people if they use the established toolchain with known working configs. I worked at a place once where it took several days to get the dev environment set up. It would have taken far longer if someone wanted to use whatever random tool they'd prefer to use.
If you code in embedded systems or FPGA its very common since you are using very specific vendor tools. A lot of enterprise companies have a "one way" kind of philosophy as well, they lock down the systems so much "for security" that you might not be able to install anything other than Eclipse or whatever is approved.
This is common in many companies, IT wants standard development environments.
Licensing issues and security configuration management are major reasons to want uniformity.
That is a massive red flag to me too. They are basically saying "you are identical to everyone else, and easily replaced."
Wanting to be able to use anybody's machine is very strange, agreed.
From a support/IT perspective though, the closer everybody's machine is, the easier the job is.
The last software shop I worked at, we had a default set of tools and configs. It was a known happy path. You were allowed to adventure off of that path, but you were mostly on your own.
Devcontainers[1] or some similar technology are a must. Use whatever specific IDE you want, but the development environment itself should be identical across everyone on the team.
No more "works on my computer" issues. The environment is always identical.
[1] https://containers.dev/
> Wanting to be able to use anybody's machine is very strange, agreed.
Very useful if people are struggling to create reliable repro steps that work for me - I can simply debug in situ on their machine. Also useful if a coworker is struggling to figure something out, and wants a second set of eyes on something that's driving them batty - I can simply do that without needing to ramp up on an unfamiliar toolset. Ever debugged a codegen issue that you couldn't repro, that turned out to be a compiler bug, that you didn't see because you (and the build servers) were on a different version? I have. There are ways to e.g. configure Visual Studio's updater to install the same version for the entire studio, which would've eliminated some of the "works on my machine" dance, but it's a headache. When a coworker shows me a cool non-default thing they've added a key binding for? I'll ask what key(s) they've bound it to if they didn't share it, so we share the same muscle memory.
It's quite common if you work in a team of engineers, or in a large company with many engineers.
Having consistent machine and OS and app configurations enables better (lower cost, higher reliability) scripting and tooling solutions in things like repos and infrastructure.
Not unlike consistency in language and compiler choices.
Or they bust don‘t want to look after a dozen different tools and their security issues.
Having a consistent setup makes it easier for your organization's IT team to support you, troubleshoot issues, etc. It also makes it easier for you to collaborate with other members of your team, or even other teams. If your coworker Fred comes to you asking for help on how to refactor something, for instance, it will go much more easily if you're running the same IDE with the same refactoring tools.
Organizations establish and enforce standards for a reason.
I don't really like VS Code either, but I personally use it because I tend to jump between a half-dozen semi-obscure languages, and VS Code is the only [0] editor that supports all of them.
[0]: Vim and Emacs have almost as good or slightly better language support, but I prefer GUIs over TUIs.
Because it is fast enough, easy to onboard to with sane defaults. MS provided initial plug-ins and the ecosystem developed.
Threat model described is not unique to VS Code
Eclipse was always a confusing product. It was a bastard child of Visual Age for Java from IBM, which was already a bastard of IBM's Visual Age for Smalltalk.
Visual Age for Java had some quirkiness being a Smalltalk IDE adapted to Java development (for example, the concept of a file and a hierarchical filesystem itself was definitely a second class citizen in Visual Age) and eclipse kind of rounded those rough edges.
But Eclipse became a victim of late 90s/early 2000s academic driven overengineering with overly complex/bureaucratic stuff like OSGI, and the support for the absurdly bureaucratic java development ecosystem at that time.
My personal reason for switching some years ago was the excellent remote session support via ssh.
I haven't reevaluated that choice in a while, but that plus LSP support (and to a lesser extent ML Auto-complete) are must-haves for me nowadays.
Never liked Eclipse, but I’ve been forced to use VSCode over my preferred JetBrains IDEs because it is the only modern mainstream editor with a competent client-server mode. As in, actually rendering the UI locally while doing all the code indexing and intelligence on the server. Corporate world would much rather maintain disposable remote VMs than help you unfuck your laptop after whatever required security upgrade installs the wrong version of a scripting language and sends everything to hell.
Have you tried Jetbrains Gateway? I’m curious whether it’s insufficient or just too recent, as I’ve eyed it a few times.
For those unfamiliar, Gateway is essentially a thin local client for Jetbrains IDEs to run remotely. The remote functionality at least is free. https://www.jetbrains.com/remote-development/gateway/
It’s not as dumb a client as VNC, but it’s close. Basic operations like typing and scrolling will stutter and lag if your connection is less than perfect. VSCode’s client is really VSCode from a UI perspective.
Gateway is discontinued
Yikes, sounds like hell.
Corporate never seems to get that git is the kind of interface you want between your computer and their servers.
Then when you trash your computer you can just get it back to the state of being able to git.
They're not using the remote VM as a server but as the development machine though. You don't want to have to git commit and push every time you need to run or even type-check your code.
I think what GP describes is actually a pretty okay solution for orgs that don't want to provider their devs with local admin privileges.
You can develop locally if you want to, and lots of people do, but it’s community support. The environment that someone else is obligated to fix for you is the remote one (which they can do by blowing away the container and then you recover your state from Git).
To myself and many others, vscode is not the defacto answer. JetBrains is. IntelliJ was miles ahead of eclipse last time I checked. Rider is miles ahead of Visual Studio. WebStorm is miles ahead of vscode for js etc.
It's not even a competition, to me. I've had to use Visual Studio instead of Rider for work the past year and it's been a very bad experience.
The biggest difference is JetBrains intellisense feels like it's reading my mind, I'll just type a couple characters and hit tab most of the time. Visual studio on the other hand has the worst intellisense I can imagine. It very frequently just messes up what I'm doing - I'll write what I want correctly, hit space and VS will just change it to something entirely different and import a package while it's at it. It's incredibly annoying. And when I actually want to use auto complete, say for example I've declared a variable on the line above and I want to use it, I'll write a couple characters and then without fail the variable I just declared on the line above is like option 6 down the list behind a bunch of crap that doesn't even make sense in the context at all. And as if it wasn't enough that the IDE is crap when it's working correctly, it very frequently craps out and just stops providing syntax highlighting and such in .razor files, or showing errors in files that compile just fine, forcing me to restart it and delete the .vs folder. Like every day.
Personally I think the only people who prefer other products than JB are people who don't know what they're missing. JB is literally just better in pretty much every way. At least the products I've used. I think I'll turn down the next job that asks me to use VS.
I’ve never written a line of Java in my life. Why would I ever use Eclipse?
VSCode is defacto standard because it’s kinda mediocre but works ok enough for every language and every platform. Microsoft created and popularized LSP so VSCode isn’t a single language IDE.
I use a mixture of code editors. My favorite is probably 10x but it only works with C++. So VSCode is just a reasonably standard unless a different editor is better for a specific use case.
The only thing that matters is extensibility/customization and speed. I want the lightest, most customizable thing that isn't emacs (for real reasons, trying to set up emacs at work is too much of pain in the ass) as my single pane of glass on any OS I care to use. If it can't do that, it doesn't live long.
I want the lightest, most customizable thing, that is also Vim. Thank god there's Vim for that. (cloning my dotfiles for instant setup on a new box)
I mean, sure, you could do that. No one said being competent was easy. Have you tried lisp?
Thing that IntelliJ and even NetBeans have going for them is that they seem like tools for getting work done. Eclipse puts more emphasis on being a platform which means you have to download and configure plugins just to get started. Great if you're a corporate shop with a standard setup that's force-pushed to every machine. Not so much if you're just getting started or working on side projects or in a startup, which is how languages and frameworks gain mindshare in the web era.
Visual Studio Code—I dunno. It's an editor more than an IDE. It lets Webdev Andys create an empty directory, put an index.ts in there, and get started right away. Yes, WebStorm does the same, but VS Code comes with decent multilanguage support for free. It's like vim or Emacs but crappier and more bloated, but a lot of people don't care about that.
I've also used Eclipse in the past but almost exclusively used vscode in recent years. It's just a phenomenal text editor. It's got fantastic multi-line selection and editing tools and searching for files is instant and you don't even need to be fully accurate with the filename. Nowadays I hardly ever use the sidebar to look for the file, I just type thr ctrl+e shortcut and insert several letters of the file and I instantly get the result. It's a small thing with a huge impact. VS, for comparison, lags a few seconds when searching files, and it misses files that are not imported into the workspace. That difference makes VS useless to me.
I loved Eclipse. I still like it quite a lot.
I stopped using it because none of the plugins for the languages I was using at the time (Ruby, Python, Erlang) were either worth a damn, or getting updated to track new language features.
I started using VSCode because IntelliJ-family IDEs will report incomplete search results as complete when they are rebuilding their search indices. To put it another way, they will tell you that a string that definitely appears in the project does not appear, if they haven't gotten around to re-adding the files that contain that string to the search index.
This to me is intolerable behavior. Others find it perfectly acceptable.
I bucket Eclipse under "heavyweight IDE". I used to use it, plus the CDT plugin, for my C++ nonsense.
Then Visual Studio's Express and later Community SKUs made Visual Studio free for ≈home/hobby use in the same bucket. And they're better at that bucket for my needs. Less mucking with makefiles, the mixed ability to debug mixed C# and C++ callstacks, the fact that it's the same base as my work tools (game consoles have stuff integrating with Visual Studio, GPU vendors have stuff integrating with Visual Studio, the cool 3rd party intellisense game studios like integrates with Visual Studio...)
Eclipse, at least for me, quickly became relegated to increasingly rare moments of Linux development.
But I don't always want a heavyweight IDE and it's plugins and load times and project files. For a long time I just used notepad for quick edits to text files. But that's not great if you're, say, editing a many-file script repository. You still don't want all the dead weight of a heavy weight IDE, but there's a plethora of text editors that give you tabs, and maybe some basic syntax highlighting, and that's all you were going to get anyways. Notepad++, Sublime Text, Kate, ...and Visual Studio Code.
Well, VSC grew some tricks - an extension API for debuggers, spearheading the language server protocol... heck, I eventually even stopped hating the integrated VCS tab! It grew a "lightweight IDE" bucket, and it serves that niche for me well, and that's a useful niche for me.
In doing so, it's admittedly grown away from the "simple text editor" bucket. If you're routinely doing the careful work of auditing possibly malicious repositories before touching a single build task, VSC feels like the wrong tool to me, despite measures such as introducing the concept of untrusted repositories. I've somewhat attempted to shove a round peg into a square hole by using VSC's profiles feature - I now have a "Default" profile for my coding adventures and a "Notes" profile with all the extensions gone for editing my large piles of markdown, and for inspecting code I trust enough to allow on disk, but not enough to autorun anything... but switching editors entirely might be a better use of my time for this niche.
In general, I believe most people see VSCode as "good enough". Maybe not the best text editor, but it's good enough at everything it does and extensible enough to the point that there's really no point to go for anything else unless you have a really good reason to.
My previous answer is thinking about editors in general. But in the case of Eclipse I'd say you're right LOL.“Java” does not explain why Eclipse is irrelevant where IntelliJ is thriving.
People forget that there was a period of time during which the Java runtime installer tried to install actual adware. You had to jump through hoops to deselect adware from being forced onto your machine, it was infuriating.
Setting up a new machine, I could choose between Eclipse (free, took forever to open, slow, asked me a million questions before it let me start working) or Visual Studio (cost money, incredibly powerful, written in C++ and was really damn fast.)
Visual Studio is mostly written in C# btw.
Back in 2005 it was mostly in C++ and it was blazing fast. IMHO VS 2005 was the most performant edition. I never liked VS 2003, felt bloated in comparison.
> Im guessing the answer is probably Java is why eclipse is out of favor.
Some people just want a text editor, whereas eclipse is “an IDE and Platform”.
I don't think that's really why VSCode succeeded or Eclipse failed.
Eclipse failed because it was slow and janky and had abysmal UX and it only supported Java well.
VSCode succeeded because it has a much more sane UX, it's way less janky, it's highly extensible and language neutral.
It's free, it has support for loads of languages, and it's kind of fashionable.
Personally I'm kind of lukewarm on VS Code, it's fine, but CLion, Visual Studio Proper, and RustRover are better for me.
I see why people use it though, it's not a bad editor at all.
For Java, I'm all over IntelliJ.
It's the license. The MIT license is what makes VSCode the defacto answer.
It also runs on the web, which makes it extremely convenient to toss into...web things. It's the code editor for the Google Cloud console, the Lambda web console, the GitHub web editor, and so on.
I'm going to guess that Eclipse doesn't have the same amount of security issues because it's not a popular target. Everyone (relatively speaking) is using VSCode or something based on it.
As I remember it, VS code was Microsoft’s response to Sublime.
Sublime was exceptionally popular for web developers throughout the 2010s.
Sublime was maintained by a single person as far as I know.
VS code was pretty much a copy of Sublime but with a much better extensions system and relatively quickly there were some great plugins that made VS code the de-facto editor for web development.
Wasn’t it a copy of Atom?
Yes, Atom was an earlier shot at building a Sublime competitor too.
I don’t know how usage of Atom compared to Sublime, but within my friends and colleagues it was only when VS code got good that people started moving away from Sublime.
I can only speak for $MY_JOB, but I'm pretty sure everyone was on Atom before VSC "got good". Atom had a good plugin ecosystem; what really drove the change was Atom's horrible performance issues whereas VSC was snappy and responsive.
What I believe also influenced the shift was that at that point in time MS had accumulated a decent amount of developer trust by giving us TypeScript and later on by acquiring GitHub. They appeared to care and have the right vision for open source.
Ahh ok, interesting. I bounced off atom immediately but VS code got me.
Nope it started as a Web IDE, going against Atom was their pivot to win market share, there are a few talks from the team if you search for VSCode history.
Let's also not forget one big reason VSCode took over and Sublime lost: VSCode is gratis and (mostly) open-source, while Sublime is proprietary.
It just happens. I was happy on netbeans, then I was forced over to eclipse, which I got used to. Then I got forced over to intellij. I'm still pissed about that (even though it's rider for me these days).
I don't mind VSCodium that much because I can put my tooling on the side (like a good unix fanboy) instead of hoping that jetbrains reimplements every other tool. Ag, grep beat IDE searches any day.
But yeah we have reach a stupid point in the industry where VSCodium asks me to trust a codebase before it will let me edit it.
> Why is VS code the defacto answer nowadays?
For what I do, there's no reasonable alternative at the moment.
I'm sure someone will correct me, but it's the only editor that correctly (for some definition of correct) allows remote editing and devcontainers:
[desktop OS] -> ssh -> [dest box]
[desktop OS] -> [devcontainer]
[desktop OS] -> ssh -> [dest box] -> [devcontainer]
[desktop OS] -> ssh (jumphost) -> [dest box] -> [devcontainer]
I won't name and shame other editors (or IDEs), but either they simply can't do that, or their performance is absolutely, shockingly, abysmal.
I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files.
If you have a jumphost chain, you can configure that in the SSH config.
I don't know what a devcontainer is exactly, but if it's a container in the sense that it runs a Linux development system, I would investigate whether that, too, could easily be set up for access via SSH or mounted locally through some other mechanism.
File access isn't the same as tool access. You need to run tools on your ssh host as well. And a devcontainer does indeed equal a (docker) container. The name is very specific and describes shipping a full developer environments so that 'you' do not have to install gcc-toolset-15, or boost 1.83, or mold, or python 3.11, and so on.
https://containers.dev/
> File access isn't the same as tool access.
Running tools remotely isn't the same as remote editing, so you'll have to forgive the misunderstanding.
> You need to run tools on your ssh host as well.
`ssh user@remote tool`. Indeed, the tool you run on the remote host could be a text editor in itself.
Interesting. Something to think about. Thanks.
Wild. I would quit my job and start selling jam at the Farmer’s Market before I went back to Eclipse! :)
If you did webshit in eclipse, especially with NPM involved, it would be just as bad. Running arbitrary code from a downloaded bundle seems normal in that world.
> Im guessing the answer is probably Java is why eclipse is out of favor.
I don't get the connection, but Java had log4j, i.e. a remote code execution vulnerability.
> Im guessing the answer is probably Java is why eclipse is out of favor.
Dude, Eclipse has been out of favor for well over ten years now due to Jetbrains IDEs (IntelliJ IDEA).
This is so insane to me. Eclipse is... Fine for Java in the sense Visual Studio is for dotnet. But man can they both be slow.
Use case depending sometimes you just need a quick editor, thats why sublime had and probably still has a huge userbase, its fast startup and flexibility. Vim, emacs and derivatives of it are the same story.
I can't imagine ever opening up eclipse to edit a zig/go/js file or project. It's too bloated.
The answer is neovim anyway. That's all anyone needs. /s
Emacs is a full IDE, not just a quick one-off editor. Its power comes from having everything scriptable from the ground up. Contrast this with the modern Extension concept, where there is a hard line between the editor's code and any changes you might want to make to its behavior.
I think vim is probably similar, but I've not gotten into it that much.
Exactly, and infact vim is very simular, neovim in my case extensible through lua scripts as an example. It's as light or feature packed as I like.
Contrast that to Eclipse and Visual Studio (not vsCode) and it's clear why the larger IDE's are falling out of favour.
VSCode main architect is one of the Eclipse authors, Erich Gamma.
Other than that, it is more fashionable to ship Chrome with applications and JavaScript is hot. /s
Eclipse remains my main Java IDE at work.
It is scary that a text editor can run hidden code just by opening a folder. We traded our safety for convenience and now we are paying the price. Users will always click the button to trust a file if they think it helps them work faster. We cannot blame them when the software design makes it so easy to make a mistake.
Tooooo be fair
Vim had also had its share of execution vulnerabilities over the years.
https://github.com/numirias/security/blob/master/doc/2019-06...
Yep, it's a shame that we keep making the same mistakes when it comes to basic security practices.
Was going to say the same thing about emacs: https://news.ycombinator.com/item?id=42256409
What is share dot google? Here's the real link: https://news.ycombinator.com/item?id=42256409
Bah. It's what chrome on Android is doing now when I ask it to give me the link. Fixed it. Thanks!
I had searched for it in the search bar at the bottom of the home screen, which opened it in a chrome window. If you tap the share icon on the top right, you get the share.google link. If you tap the three dots and then something like "copy link" you get the actual link.
Doesn't it ask you if you trust a folder when you open it?
You are right that the computer asks you. But people click yes because they are used to ignoring warning signs. The software relies on people making perfect choices every time and that never happens.
It should tell me what should I look before I trust it. Not trusting the workspace means I might as well use Notepad to open it. I wouldn't think that tasks.json include autorun tasks in addition to build actions.
Who remembers autorun.exe
I always wondered why. Now I finally know that it auto runs code in that folder.
Who thought this is a good idea and why wasn't it specified in ALL CAPS in that dialog?
Is it even documented anywhere?
Very infrequent vscode user here, beginning to think it's some kind of Eclipse.
I mean it's not in caps, but it's literally the first line in the dialog after the header:
https://code.visualstudio.com/docs/editing/workspaces/worksp...
I'm big on user first, if that dialog had sirens blaring, a gif and ten arrows pointing that "THIS MAY EXECUTE CODE" and people still didn't get the idea, I'd say it needs fixing. It can't be said that they didn't try or that they hid it though.
>"THIS MAY EXECUTE CODE"
So at the end of the day its still unclear whether it executes code or not? Just say "this WILL execute code" and specify exactly which code it tries to execute by default.
I don't know about you people, but I always read this as "it may execute code if you run a build step".
Not "I will execute autorun.inf like an idiot."
And NO. I do not want my IDE to execute code when i open files for editing. I want it to execute code only as part of an explicit step that I initiate.
Yeah but it's one of those useless permission requests along the lines of "Do you want this program to work or not?"
They're pawning off responsibility without giving people a real choice.
It's like the old permission dialog for Android that was pretty much "do you want to use this app?". Obviously most people just say yes.
There's a reason Google changed that.
To be fair I'm sure Microsoft would switch to a saner permission model if they could but it's kind of too late.
It's not a false choice - "Trust" and "don't trust" are both perfectly viable options. The editor works fine in restricted mode, you just won't have all your extensions enabled.
> We traded our safety for convenience
Not the first time. Same with LLMs.
Not a VSCode user, so a genuine question: what are practical use-cases in which you want VSCode to automatically execute a task only by opening a folder?
Is it only for convenience so it already `npm i` or `npm start` without you having to do anything, or are there any other legitimate purposes beyond that?
Apart from this feature specifically, in general people would like their IDE to run language servers, set up build systems, and any number of other things which are likely to require some configuration which allows executing some code in the folder to work. VS code has a restricted mode to prevent this, which you need to accept a dialog to disable, but it also disables most of its features.
> in general people would like their IDE to run language servers, set up build systems, and any number of other things
That I understand, I’m mainly wondering why all that would have to happen automatically by merely opening a folder.
My personal preference may differ here, but for things like running a build or starting a dev server, I usually prefer to trigger them manually, and not have them silently executed only by me browsing through the sources.
Therefore I’m trying to understand whether there are legitimate use-cases for this “auto-run on open folder” feature besides the obvious convenience aspect of saving one or two extra clicks.
When I used it, the one use case I used it was to automatically launch a Jekyll server - if I'm working on a site I'm almost certainly going to want to look at my changes in the browser. Now that I've switched I just run one extra command, it wasn't a big saving, but it was kind of nice.
Is tasks.json automatically run? I thought additional user interaction was required?
The article doesnt' claim it's executed straight up either ("can result") but it's pretty ambiguous:
> When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system.
In the screenshot the task is named "node" - so it's a bit like embedding a malicious Makefile target as a backdoor.
Except harder to spot since it's in a obscure .vscode/somethingsomething json file. (And probably you can easily fool GH Copilot to run it)
You can specify:
In tasks.json, which I use for automatically `git fetch`ing on a few projects. While I don't recall it's interaction with first run / untrusted folder dialogs, it's entirely automatic on second run / trusted folders.Does it matter that much? I don't think there is any "safe" build system. Users will try to build project sooner or later. With Maven it is easy to add a plugin with harmful payload as dependency, you won't spot it in "source", unless you carefully review every dependency. IDEs need containers/isolation and they need it now. Instead we got that "Do you trust this project" dialog.
I'm moving all my development to a remote VM so I can use a coding assistant without worrying too much. I use VS Code's "Remote - SSH" plugin to connect.
I'm wondering if that helps. If I "trust" a remote directory, is there an exploit that can get to my laptop?
There's enough complicated machinery that I'm thinking the answer is likely yes, but perhaps this has been vetted.
Unfortunately according to Microsoft themselves, the answer is yes https://marketplace.visualstudio.com/items?itemName=ms-vscod...
> A compromised remote could use the VS Code Remote connection to execute code on your local machine.
Ah well. Since I'm mostly reading code in the VM, I should come up with a better file browser.
Is this 'task' feature really useful? I'd say applications like IDEs and text editors should not have automatic arbitrary execution of code in the first place. 'eval' should be blocked and extensions/plugins should have only very limited power to execute external logic (such as processes for LSP) or require allowlisting manually every process.
I am fully moving from local electron based vscode to using vscode-server inside docker inside a vm. It has just so many advantages besides security eg. being able to have multiple workspaces in tabs instead of separate electron windows, and having all the docker/vm tooling available. This can replace remote vscode, devcontainers and electron in a nice package. There is just no reality in which vscode with electron running as user account on a bare machine can be secure not even thinking about agents in the mix. We are working on a custom browser called darc based on chromium IWAs and controlled frames instead of electron and optimised for this. (apache 2.0)
Interesting. Link to custom browser repo?
pre alpha, xenon is like a browser framework, darc the reference browser, the vscode dev browser is like a dev focused release. https://xe.dev/darc
Maybe I'm a dinosaur in this regard but I don't like nor trust any of these desktop application that are really just Web technologies with an embedded browser eg Discord.
They're resource hogs and the attack surface is huge. You're basically betting that automatic code that's run won't find a vulnerability and escape the sandbox from an entire browser.
I have way more trust in Jetbrains IDEs and the JVM as a sandbox vs HTML/CSS/JS.
Still, I'm always impressed at the ingenuity of the people who come up with these attacks and the people who find them.
Won’t IDEA automatically index/execute some Gradle code when possible? As soon as you execute an arbitrary binary/script from the project directory, the isolation of the JVM doesn’t matter.
This particular vulnerability relied upon passing the require function to a scope to allow the loading and running of arbitrary code. This is what I tend to call a blacklist approach. You're saying in this sandbox certain features can't be used because they will allow escape.
The alternative is a whitelist approach. Instead of disallowing dangerous features you're enabling only the features you need.
So a build system like Gradle or Maven (same thing really) has a limited set of primitives it is allowing access to. It's not loading, say, the entire JVM and all the Java core libraries and then listing all those you can't use.
You see the difference? If nothing else, the blacklist approach is going to fail when the virtual machine (or whatever) adds a new API call upstream and it's added without intent to the sandbox by simply doing an update where nobody has thought to disable it.
Another way of looking at this is Gradle isn't being compiled into Java bytecode and run in the same environment as the IDE (sandboxed or otherwise). That is inherently riskier.
Same here, I only use VSCode because in some scenarios I have no choice, from regulated IT environments, or product SDKs with plugins only for it.
When I can avoid it, the better.
Yep. You’d think using web tech would make it really easy to sandbox any 3rd party JavaScript that gets run. But I suppose sandboxing is simply too inconvenient.
Because that isn't how it happens, the plugin model relies on external processes with OS IPC, most of them rely on basic process security model, and aren't even implemented in JavaScript due to performance.
Between long lost of dependencies, LLM and these threat models; developing inside containers should be default workflow.
I wonder what happens if you open the repo in VSCode Online through GitHub?
What is the risk profile when running untrusted code in a GitHub codespace under VS Code (other than access to and env vars or secrets attached to the code space)?
"Code provides features that may automatically execute files in this folder. If you don't trust the authors of these files, we recommend to continue in restricted mode as the files may be malicious."
If you proceed with "Trust Project" you're at your own fault.
You know what would be better? Telling me explicitly what file/script will run and asking permission for that. A blanket message every time is no better than the cookie popups and doesn’t tell me if the project has 0 files that will run.
The "trust project" feature has been designed to be so extremely intrusive and annoying that the first thing I do is to completely disable it whenever I install VS Code on a new computer. This "solution" was just done to tick some box and put the blame on the user when a security incident happens. It's pretty similar to Windows Vista where it annoyed you with a disruptive popup so many times during the normal course of actions that most people ended up disabling the whole UAC system. Overall security goes down, and Microsoft has a nice excuse.
> It's pretty similar to Windows Vista where it annoyed you with a disruptive popup so many times during the normal course of actions that most people ended up disabling the whole UAC system.
Nothing changed post-Vista. It's exactly the same system in Windows 11 doing exactly the same thing. It did, however, get developers to change how they do things.
To be honest, the solution here is probably more dialogs like this, not less. Having one single "Trust everything here but if you don't then nothing will work" box is hardly a good way to go.
Vista's annoyance had a purpose, to get program developers to change things to run without escalation. They didn't want you disabling UAC, and these days it breaks things to disable UAC.
By only having an upfront project-wide toggle, VS Code is much worse.
Yeah imagine if at boot Windows Vista gives you the UAC "Do you TRUST all the software you are going to run today?" and if you say yes then it just allows any random code to do whatever it wants.
tasks.json is the problem here, who thought that was a good idea?
Agree. But the first build you do after that clone/checkout is risky too. Maybe not as wide open, as the build-tool makers are a line of defence if they're acting on classes of vuln.
When the project is opened, Visual Studio Code prompts the user to trust the repository author. If that trust is granted, the application automatically processes the repository’s tasks.json configuration file, which can result in embedded arbitrary commands being executed on the system.
Sigh. It's so Microsoft to just run random stuff.
Of course, in the Linux world, we have "Install with"
A great reason why you should switch to Zed.
I was reminded of this comment when I saw the latest Zed release removing a list of tool calls from the default always_allow list. Yikes!
https://github.com/zed-industries/zed/compare/v0.220.2...v0....