121–130 of 488 posts
friendly reminder: - disable auto-updates for extensions in VS Code/Cursor - use static analysis for GitHub Actions to catch security issues in pre-commit hook and on ci: https://github.com/zizmorcore/zizmor - set locally: pnpm config set minimum-release-age 4320 # 3 days in minutes https://pnpm.io/supply-chain-security - for other package managers check: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e..…
so how did they exfiltrate the information without noticing? what OS was the developer using? what security measures were they using? yesterday discussion https://news.ycombinator.com/item?id=48191680
The security measure that the developer didn't use was completely refusing to use vscode. vscode has no security model. It's not like swiss cheese where there are holes and some of the go all the way through. vscode is all hole with some cheese on the side. There is absolutely no isolation between the front-end process, the backend size (the thing that runs in the remote or the devcontainer), and any extensions or an…
Earlier quoted context omitted.
Or you can just refuse to use random extensions. I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE, without having to make a whole IDE from scratch. I have since moved on to making my own IDE, mostly because I hate Electron and its >1gb memory footprint, but vscode served me so much better than…
Kind of. A vscode workspace can trivially execute code on the machine that runs the server end of vscode. (This is how building works -- there is no sandbox unless the workspace config explicitly uses some kind of sandbox.) So the workspace can usually trivially elevate permissions to take over the vscode server, including installing extensions on it without asking you. In principle, there is a teeny tiny bit of isol…
friendly reminder: - disable auto-updates for extensions in VS Code/Cursor - use static analysis for GitHub Actions to catch security issues in pre-commit hook and on ci: https://github.com/zizmorcore/zizmor - set locally: pnpm config set minimum-release-age 4320 # 3 days in minutes https://pnpm.io/supply-chain-security - for other package managers check: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e..…
friendly reminder: use vim :)
I'm more surprised hackers found a large enough uptime window to do this.
It's gotten a lot worse (and made news) more recently, as the downtime as increased.
I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.
I really hope this pushes users (here: devs and maintainers) to decrease their reliance on Microsoft and especially stop outsourcing security to them. Migrate off vscode already.
I guess I'd say "you take my VS Code ... willingly ... but only after M$ fucks it up and makes me not want it anymore (like they've done to everything else they acquired)".
friendly reminder: - disable auto-updates for extensions in VS Code/Cursor - use static analysis for GitHub Actions to catch security issues in pre-commit hook and on ci: https://github.com/zizmorcore/zizmor - set locally: pnpm config set minimum-release-age 4320 # 3 days in minutes https://pnpm.io/supply-chain-security - for other package managers check: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e..…
friendly reminder: use vim :)
I'm more surprised hackers found a large enough uptime window to do this.
For those not getting the joke, GitHub has had an increasingly difficult keeping itself up since Microsoft acquired them. It's gotten a lot worse (and made news) more recently, as the downtime as increased.
Earlier quoted context omitted.
> I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE, Dude, get real. We don't all have the luxury of being able to engage in endless IDE extension programming side quests just to do our day jobs. And even if we did, there's the reality that whatever you produce is probably not nearly as feature…
> just to do our day jobs. Ah, there it is. The root of most problems in the software industry: people who hate programming and avoid doing it as much as possible, because they only got into it for the money. I have no problem writing extensions in my spare time because programming is fun. Because I know how to program, like, actually program and not just copypaste stuff off StackOverflow, it doesn't take years to wr…
Yeah, not the case at all. I love programming, I've been doing it since I was a kid, for over 30 years. But I DO have to earn a living, and I'd rather spend free time programming things that interest me. Writing IDE extensions and tooling all the way down to the bare metal because I can't be absolutely sure at all times that node.js code doesn't contain a virus is not one of those things.
Earlier quoted context omitted.
no pruning of repos?
No OP but I used to work at a large company with a similar number of repos. When I left about a year ago, we had just started (after being on Github for almost 8 years) an ongoing project of first archiving old/outdated repos in place, and then moving them to an "archived" sub-org, and waiting to see if anyone complained. Previously no one wanted to outright delete or remove repos because of the risk that someone som…