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

181–190 of 460 posts

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

#181

Post by halflife »

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…

This sucks for libraries that download native binaries in their install script. There are quite a few.

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

#182

Post by nicoritschel »

One of my projects uses an impacted version. However, we use bun as a package manager. Thrilled bun protected us by default!

> executing arbitrary scripts represents a potential security risk, so—unlike other npm clients—Bun does not execute arbitrary lifecycle scripts by default.

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

#183

Post by hardwaregeek »

christophilus wrote: post #61
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…

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

That’s called the original Go package manager and it was pretty terrible

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

#184

Post by halflife »

littlecranky67 wrote: post #169
threetonesun wrote: post #118

Earlier quoted context omitted.

npm workspaces and npm scripts will get you further than you might think. Plenty of people got along fine with Lerna, which didn't do much more than that, for years. I will say, I was always turned off by NX's core proposition when it launched, and more turned off by whatever they're selling as a CI/CD solution these days, but if it works for you, it works for you.

Killer feature of NX is its build cache and the ability to operate on the git staged files. It takes a couple of minutes to build our entire repo on an M4 Pro. NX caches the builds of all libs and will only rebuild those that are affected. Same holds true for linting, prettier, tests etc. Any solution that just executes full builds would be a no-starter for all use cases.

Don’t forget task dependency tree, without that you will have a ton of build scripts

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

#185

Post by cedws »

pharrington wrote: post #152
cedws wrote: post #108

Earlier quoted context omitted.

Yes but it's the fact that cargo can pull a massive unreviewed dependency tree and then immediately execute code from those dependencies that's the problem. If you have a repo with a Makefile you have the opportunity to review it first at least.

You are allowed to read Cargo.toml.

Cargo.toml does not contain the source code of dependencies nor transient dependencies.

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

#187

Post by zahlman »

saberience wrote: post #174
OJFord wrote: post #86

Earlier quoted context omitted.

It doesn't have to be a deliberate 'attack', Claude can just do something absurdly inappropriate that wasn't what you intended. You're absolutely right! I should not have `rm -rf /bin`d!

I would say this is a feature, not a bug. Terminal and Bash or any shell can do this, if the user sucks. I want Claude Code to be able to do anything and everything, that's why it's so powerful. Sure, I can also make it do bad stuff, but that's like any tool. We don't ban knives because sometimes they kill people, because they're useful.

> Terminal and Bash or any shell can do this, if the user sucks.

But at least they will do it deterministically.

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

#188

Post by cedws »

pharrington wrote: post #151
cedws wrote: post #65

Earlier quoted context omitted.

Rust makes me especially nervous due to the possibility of compile-time code execution. So a cargo build invocation is all it could take to own you. In Go there is no such possibility by design.

You're confusing compile-time with build-time. And build time code execution exists absolutely exists in go, because that's what a build tool is. https://pkg.go.dev/cmd/go#hdr-Add_dependencies_to_current_mo...

I don't really get what you're trying to say, go get does not execute arbitrary code.

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

#189

Post by orblivion »

fsflover wrote: post #28
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…

> I do most of my coding in a VM now Perhaps you may be interested in Qubes OS, where you do everything in VMs with a nice UX. My daily driver, can't recommend it enough.

Yeah I use Qubes for my "serious" computing these days. It comes with performance headaches, though my laptop isn't the best.

I wonder about something like https://secureblue.dev/ though. I'm not comfortable with Fedora and last I heard it wasn't out of Beta or whatever yet. But it uses containers rather than VMs. I'm not a targeted person so I may be happy to have "good enough" security for some performance back.

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

#190

Post by sfink »

skydhash wrote: post #90
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…

I actually loathe those progress trackers. They break emacs shell (looking at you expo and eas). Why not print a simple counter like: ..10%..20%..30% Or just: Uploading… Terminal codes should be for TUI or interactive-only usage.

Carriage returns are good enough for progress bars, and seem to work fine in my emacs shell at least:

    % echo -n "loading..."; sleep 1; echo -en "\rABORT ABORT"; sleep 1; echo -e "\rTerminated"
works fine for me, and that's with TERM set to "dumb". (I'm actually not sure why it cleared the line automatically though. I'm used to doing "\rmessage " to clear out the previous line.)

Admittedly, that'll spew a bunch of stuff if you're sending it to a pager, so I guess that ought to be

    % if [ -t 1 ]; then echo -n "loading..."; sleep 1; echo -en "\rABORT ABORT"; sleep 1; echo -e "\rTerminated"; fi
but I still haven't made it to 15 dependencies or 200 lines of code! I don't get a full-screen progress bar out of it either, but that's where I agree with you. I don't want one.
Post reply on HN