Live data from Hacker News

Malicious versions of Nx and some supporting plugins were published

github.com

131–140 of 460 posts

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

#131
post #107

Earlier quoted context omitted.

Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.

The system package manager and the language package/dependency managers do a very different task. The distro package manager delivers applications (like Firefox) and a coherent set of libraries needed to run those applications. Most distro package managers (except Nix and its kin) don't allow you to install multiple versions of a library, have libs with different compile time options enabled (or they need separate pa…

But I don’t really want your version of the application, I want the one that is aligned to my system. If some feature is really critical to the application, you can detect them at runtime and bailout (in C at least). Most developers are too aggressive on version pinning.

> Most distro package managers (except Nix and its kin) don't allow you to install multiple versions of a library

They do, but most distro only supports one or two versions in the official repos.

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

#133

Earlier quoted context omitted.

So we’re declaring all software with auto-updaters as RCE? That doesn’t seem like a useful distinction.

That’s pretty much the definition. Auto updating is trusting the developer (Almost always a bad idea).

Simply running the software means trusting the developer. But even then, do you really read the commits comprising the latest Firefox update? How would I review the updates for my cell phone? I just hit "okay", or simply set up auto updates.

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

#136
post #18

the truly chilling part is using a local llm to find secrets. it's a new form of living off the land, where the malicious logic is in the prompt, not the code. this sidesteps most static analysis. the entry point is the same old post-install problem we've never fixed, but the payload is next-gen. how do you even defend against malicious prompts?

Run Claude Code in a locked down container or VM that has no access to sensitive data, and review all of the code it commits?

As a separate locked-down user would probably also work.

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

#137
post #112
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.

Every feature is also a potential vulnerability.

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

#138

Earlier quoted context omitted.

That’s pretty much the definition. Auto updating is trusting the developer (Almost always a bad idea).

Simply running the software means trusting the developer. But even then, do you really read the commits comprising the latest Firefox update? How would I review the updates for my cell phone? I just hit "okay", or simply set up auto updates.

I trust Debian, and I do trust Firefox. I also trust Node, NPM, and Yarn. But I don’t trust the myriad packages in some rando projects. So who I trust got installed by apt. Anyone else is relocated to a VM or some kind of sandbox.

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

#139
post #6

So any process on my computer could just start using Claude Code for their own purposes or what? o_O

Any postinstall script can add anything to your bashrc. I sometimes wonder how the modern world hasn't fallen apart yet.

I don't think this solves the world but as a quickfix for this particular exploit I ran:

sudo chattr -i $HOME/.shrc

sudo chattr -i $HOME/.profile

to make them immutable. I also added:

alias unlock-shrc="sudo chattr -i $HOME/.shrc"

alias lock-shrc="sudo chattr +i $HOME/.shrc"

To my profile to make it a bit easier to lock/unlock.

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

#140
post #54

Earlier quoted context omitted.

> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…

Fully agree. So many people are so drunk on the kool aid, I often wonder if I’m the weirdo for not wanting dozens of third party libraries just to build a simple HTTP client for a simple internal REST api. (No I don’t want tokio, Unicode, multipart forms, SSL, web sockets, …). At least Rust has “features”. With pip and such, avoiding the kitchen sink is not an option. I also find anything not extensively used has bug…

If you don’t want Tokio I have bad news for you. Rust doesn’t ship an asynchronous runtime. So you’ll need something if you want to run async.
Post reply on HN