51–60 of 116 posts
> To those folks, I am sorry, but this is one of the few levers I have to try to influence MSRC and the security posture of VSCode Someone is going to be blacklisted by Microsoft.
If you like VSCode but don't like Microsoft, try Zed (zed.dev).
Zed downloads random binaries on startup without any permissions prompts. No thanks.
I don’t really understand why more devs don’t try Neovim. Maybe it’s just my preference, but I like having a small setup where I know what is installed and what is running. With VSCode, browser IDEs, extensions, sync, tokens, and random plugins, it gets hard to tell what actually has access to what.
I noticed that is quite hard to make people change habits regarding software. There is shortcuts to learn and we might feel slow at first which reinforces the feeling of « it’s not better ». It takes a while to get used to nvim, once there it’s faster but that explain why many people stay in their confort zone
This is a very good writeup. Zooming way out (perhaps to the point of useless observation), it's a pity that the web embedded VSCode editor is signed into GitHub at all . Defense-in-depth or not, a huge vulnerability surface arises from that original sin. It'd be like if you had a god-permissioned GitHub API token stored in world-readable plaintext on your workstation for the malicious-NPM-package-of-the-week to find…
This is going to get worse and worse. I recently noticed AI harness (e.g. OpenCode) downloading random npm packages in the background and litter them everywhere in a few place in ~ and in your project dir, all without telling/asking you.
What's worse is that people don't seem to care even the devs.
This is a very good writeup. Zooming way out (perhaps to the point of useless observation), it's a pity that the web embedded VSCode editor is signed into GitHub at all . Defense-in-depth or not, a huge vulnerability surface arises from that original sin. It'd be like if you had a god-permissioned GitHub API token stored in world-readable plaintext on your workstation for the malicious-NPM-package-of-the-week to find…
I don’t really understand why more devs don’t try Neovim. Maybe it’s just my preference, but I like having a small setup where I know what is installed and what is running. With VSCode, browser IDEs, extensions, sync, tokens, and random plugins, it gets hard to tell what actually has access to what.
I wish I could add “and I never looked back”, but honestly in the past year or two Neovim started regularly breaking my setup (approximately every upgrade). Had some inklings it might happen eventually… Strictly speaking, 10 years in, nvim is yet to have its first stable version released—which means technically one can’t blame it for instability, but which is useful to keep in mind.
Considering going back to plain vim. I’m sure I will lose many niceties, but hopefully it would not require me to troubleshoot broken functionality in the middle of work.
This is a very good writeup. Zooming way out (perhaps to the point of useless observation), it's a pity that the web embedded VSCode editor is signed into GitHub at all . Defense-in-depth or not, a huge vulnerability surface arises from that original sin. It'd be like if you had a god-permissioned GitHub API token stored in world-readable plaintext on your workstation for the malicious-NPM-package-of-the-week to find…
> temporary per-repo permission scope or token that allowed only pull and push to the repo in question How about pull from the repo but only push to a staging area from which the user, but not the token, can push for real? Frankly, LLM agents should do this too. Letting your LLM push seems foolhardy to me.
The attack surface that makes this particularly nasty is that VSCode extensions run with the same trust level as the editor itself, and most developers have dozens installed without reviewing their permissions. A malicious or compromised extension silently exfiltrating GitHub tokens is undetectable without network monitoring. This is a good argument for running extensions in isolated profiles.
Even with network monitoring, exfil to Github itself can be very hard to stop unless you SSL intercept and have very strict URL allow lists.
Best is to move away from Github, move to self hosted internal Gitlab/Forgejo and block Github completely.