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?
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.
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.
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?
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.
>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.
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.
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.
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.
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!
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
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.
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.
> 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.
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.
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.
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.
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.
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.)
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.
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.
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.
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
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.
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.
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.
Readit News
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.
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.
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?
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.
At some point the dev has to take responsibility.
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 :)
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.
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?
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.
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.
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...
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.
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
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.
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.
Then copy-paste my default .dev-container directory and reload.
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.
https://news.ycombinator.com/item?id=46435142
Which: They do actually have some container-like sandboxing tech around applications (“iTerm wants to access your downloads folder”).
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.
Though this autorun feature is crazy and should be completely off by default.
Dead Comment
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.
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...
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...
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.
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.
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.
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!
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.
> I don't use it because it's so dog slow.
You might find it runs better with fewer plugins.
[0]: Vim and Emacs have almost as good or slightly better language support, but I prefer GUIs over TUIs.
Threat model described is not unique to VS Code
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.
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.
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.
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.
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.
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 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.
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.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.)
Some people just want a text editor, whereas eclipse is “an IDE and Platform”.
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.
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 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.
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.
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.
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.
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.
Deleted Comment
> 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.
Dude, Eclipse has been out of favor for well over ten years now due to Jetbrains IDEs (IntelliJ IDEA).
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
I think vim is probably similar, but I've not gotten into it that much.
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.
Anything else that should be locked down?
So a malicious repo can easily override it... if you say you trust it.
2. Install Vim / Emacs / Sublime / Helix
3. ????
4. Profit
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
Vim had also had its share of execution vulnerabilities over the years.
https://github.com/numirias/security/blob/master/doc/2019-06...
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.
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.
Not the first time. Same with LLMs.
> 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)