Live data from Hacker News

Microsoft's open source tools were hacked to steal passwords of AI developers

techcrunch.com

201–210 of 211 posts

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#202

Earlier quoted context omitted.

It only spreads if you run the code...

No, it spreads if you open a folder. That's the point why developers all underestimate the worm's capabilities.

In a tool that's dumb enough to run code from untrusted folders.

`cd folder` does nothing.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#203
post #189

Earlier quoted context omitted.

I just finished watching that series, so I can pick up these references. Nothing like being 20 years late to the party

Peter Pan came out in 1953 https://www.reddit.com/r/BSG/comments/12e31w3/so_i_was_today...

Well, neither myself of the person I replied to used this as a reference. You've missed the point

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#204

Earlier quoted context omitted.

No, it spreads if you open a folder. That's the point why developers all underestimate the worm's capabilities.

In a tool that's dumb enough to run code from untrusted folders. `cd folder` does nothing.

> "cd folder" does nothing.

That's like recommending to use the xterm on Windows. Statistically, nobody uses their computer that way anymore. The world has moved on since the 1990s.

I was only not affected because I use a heavily customized VIM, but even there can I not control how package managers like npm, pip or composer or go are behaving, because they will happily execute the malware payloads on install.

And time wise it's an absurd thing to ask people to manually download all whl files of all their dependencies, extract all those files, and then check whether there was malware in them or not. It's simply not possible to do manually.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#205

Earlier quoted context omitted.

> https://github.com/ashishb/amazing-sandbox Does your Docker backend run commands in rootless containers? I skimmed the code but didn't see anything to confirm this.

Right now, not. Eventually, they will. You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.

I hope you see the (IMO, obvious) problem.

1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary. 2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#206
post #13

What follows next is purely speculation and it is based on my own observations and thoughts but based on what I've seen the old RBAC models, while being almost broken before, now it is fully broken, with the fact that now coding assistants and engineers are working on multiple unrelated projects simultaneously - especially working on wild experiments they had no time for previously. The risk of supply chain issue has…

My work projects are on separate hardware in a separate network that doesn't allow for AI agents... for better and worse.

I have used agents for a few components externally, that I've adopted/used internally... but those were 100% code reviewed, not vibe coded. One was an intro animation using a couple SVGs and CSS. Another was an image zoom control where I needed some behaviors and not a lot extra. Both significantly tweaked by hand as well.

I'm more a proponent of working as a gatekeeper as opposed to vibe coding... Though I think a better term would be nice.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#207
post #48

Earlier quoted context omitted.

I argued for years that we had too few workers for our total project count and management argued that most projects were idle and so it was fine to have so many per worker. Welp.

I think web-based IDEs like GitHub Codespaces (but even VSCode with tunnels) is part of the solution because at the very least you can get an isolated dev environment per project. I've been advocating for this for as long as I remember. Unfortunately, most developers don't like them so it is a though sell.

I like the remote editing tools for VS Code quite a bit...

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#208

Earlier quoted context omitted.

I really tried to give vscode an honest shot. I couldn't find anything about it that was even half as good as a real text editor. It made writing code feel like a chore. I usually love writing code.

What is a real text editor, by your estimation? NVim? Emacs? Genuinely curious. I use VSCode/Codium since I maintain a GUI stack for general usage. But I have all the terminal tools installed for my work there as well. I hate customizing things too, which I find is necessary if you want to get the most out of terminal text editors. VSCode is pretty good out of the box, with terminal access and everything built in. Je…

I'll say my biggest recent gripe with VS Code, is since they started collapsing bits in the terminal, when I type a command and hit enter, if I start typing the next command before the first command is done, the input gets mangled.

It doesn't happen in MS Terminal (new Windows Terminal) and it doesn't happen in Tabby (which is also Electron+xterm.js), so it's a recent unique to VS Code bug... and it's annoying to no end for me. I actually rely on the integrated code terminal a lot.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#210

Earlier quoted context omitted.

Right now, not. Eventually, they will. You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.

I hope you see the (IMO, obvious) problem. 1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary. 2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.

> 1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary.

This has been discussed in detail earlier - https://news.ycombinator.com/item?id=47612726

Further, on Mac OS, you can use `--mode=native` for Mac's native sandboxing (seatbelt).

> 2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.

That's not always the case. You can run rootless containers or you can use containerization like Podman which does not run as root.

Post reply on HN