Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious versions of Nx and some supporting plugins were published

github.com

Post reply on HN
Print view View original

411–420 of 460 posts

Re: Malicious versions of Nx and some supporting plugins were published

#411

Post by vendiddy »

dakiol wrote: post #112
f311a wrote: post #11

People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…

Easier solution: you don’t need a progress bar.

And if you really do? Print the percentage to stdout.

Re: Malicious versions of Nx and some supporting plugins were published

#412

Post by internet_points »

homebrewer wrote: post #211
inbx0 wrote: post #125

Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…

I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers: #!/usr/bin/bash bin=$(basename "$0") exec bwrap \ --bind ~/.cache/nodejs ~/.cache \ --bind ~/code ~/code \ --dev /dev \ --die-with-p…

Thanks, handy wrapper :) Note:

    --symlink /usr/lib /lib64 \
should probably be `/usr/lib64`

and

    --share-net \
should go after the `--unshare-all --unshare-user`

Also, my system doesn't have a symlink from /tmp to /var/tmp, so I'm guessing that's not needed for me (while /bin etc. are symlinks)

Re: Malicious versions of Nx and some supporting plugins were published

#413

Post by vendiddy »

girvo wrote: post #357
f311a wrote: post #11

People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…

> People really need to start thinking twice when adding a new dependency I've been preaching this since ~2014 and had little luck getting people on board unless I have full control over a particular team (which is rare). The need to avoid "reinventing the wheel" seems so strong to so many.

I find if I read the source code of a dependency I might add,

it's common that the part that I actually need is like 100 LOC rather than 1500 LOC.

Please keep preaching.

Re: Malicious versions of Nx and some supporting plugins were published

#414

Post by fph »

roenxi wrote: post #4

Honest to goodness, I do most of my coding in a VM now. I don't see how the security profile of these things are tolerable. The level of potential hostility from agents as a malware vector is really off the charts. We're entering an era where they can scan for opportunities worth >$1,000 in hostaged data, crypto keys, passwords, blackmail material or financial records without even knowing what they're looking for whe…

Part of the problem is the traditional PC security model (Linux / Windows). "All the executable files I run are trusted and have access to all my personal files" doesn't work anymore in 2025. Android fixed this for the most part, but on PC SELinux is all we have and it's painful to use.

Re: Malicious versions of Nx and some supporting plugins were published

#415

Post by Perz1val »

0xbadcafebee wrote: post #64

Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository). But that's just the delivery mechanism of the attack. What caused the attack to…

What an entitled idea, if you want a guarantee then buy a license. Wanting to hold people accountable for an open source library that you got for free is the same bullshit attitude as google with their hostile developer verification.

Re: Malicious versions of Nx and some supporting plugins were published

#416

Post by miggol »

Gander5739 wrote: post #273
hombre_fatal wrote: post #235

Earlier quoted context omitted.

One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware. It's one big macOS/Windows/Linux install where everything from crypto wallets to credential files to gimmick apps are all neighbors. And the tools for partitioning these things are all pretty bad (and mind you I'm about to pitch something probably even worse). When I'm running a few Win…

Like Qubes?

Qubes really is the trailblazer in this regard. You can get pretty close with distroboxes on Linux as well.

When a project requires a certain Python version a virtualenv suffices. But when you need a specific Python and NPM version then I might as well make a distrobox. Set a custom home and the project is isolated, speaking only to my IDE over LSP, and also to my web browser I suppose.

This only protects the developer themselves of course, but it's a start.

Re: Malicious versions of Nx and some supporting plugins were published

#417

Post by johnisgood »

homebrewer wrote: post #211
inbx0 wrote: post #125

Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…

I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers: #!/usr/bin/bash bin=$(basename "$0") exec bwrap \ --bind ~/.cache/nodejs ~/.cache \ --bind ~/code ~/code \ --dev /dev \ --die-with-p…

Firejail is quite good, too. I have been using firejail more than bubblewrap.

Re: Malicious versions of Nx and some supporting plugins were published

#418

Post by johnisgood »

inbx0 wrote: post #125

Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…

At this point why not just avoid npm (and friends) like the plague? Genuinely curious.

Re: Malicious versions of Nx and some supporting plugins were published

#419

Post by Perz1val »

chmod775 wrote: post #161

> Previously you might've been able to say "okay, but that requires the attacker to guess the specifics of my environment" - which is no longer true. An attacker can now simply instruct the LLM to exploit your environment and hope the LLM figures out how to do it on its own. Not to toot my own horn too much, but in hindsight this seems prescient. https://news.ycombinator.com/item?id=45007074

Hello, I'm an attacker, do you have any new ideas? (obligatory /s)

Re: Malicious versions of Nx and some supporting plugins were published

#420

Post by Perz1val »

mathiaspoint wrote: post #13

I always assumed malware like this would bring its own model and do inference itself. When malware adopts new technology I'm always a little surprised by how "lazy"/brazen the authors are with it.

If they were not lazy, they've might as well gotten a normal job
Post reply on HN