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

111–120 of 460 posts

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

#111

Post by bethekidyouwant »

OJFord wrote: post #86
saberience wrote: post #80

Earlier quoted context omitted.

So what? It doesn't run by itself, you have to choose to run it. We have tons of apps with loads of permissions. The terminal can also mess with your filesystem and run commands... sure, but it doesn't open by itself and run commands itself. You have to literally run claude code and tell it to do stuff. It's not some living, breathing demon that's going to destroy your computer while you're at work. Claude Code is th…

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 don’t use Claude, but can it really run commands on the cli without human confirmation? Sure there may be a switch to allow this but If in that case all but the most yolo must be using it in a container?

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

#112

Post by dakiol »

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.

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

#113

Post by Bridged7756 »

exDM69 wrote: post #91
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.

The same applies to any Makefile, the Python script invoked by CMake or pretty much any other scriptable build system. They are all untrusted scripts you download from the internet and run on your computer. Rust build.rs is not really special in that regard. Maybe go build doesn't allow this but most other language ecosystems share the same weakness.

In JavaScript just the npm install can fuck things up. Pre-install scripts can run malicious code.

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

#114

Post by 3036e4 »

hvb2 wrote: post #99
christophilus wrote: post #61

Earlier quoted context omitted.

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.

Is that realistic though? What you're proposing is letting go of abstractions completely. Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself? That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.

Small, trivial, things, each solving a very specific problem, and that can be fully understood, sounds pretty amazing though. Much better than what we have now.

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

#115

Post by quotemstr »

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.

Try mistty

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

#116

Post by [deleted] »

skydhash wrote: post #100
jpalawaga wrote: post #77

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).

[deleted]

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

#117

Post by skydhash »

eightys3v3n wrote: post #73
terminalbraid wrote: post #48

Earlier quoted context omitted.

Which operating system lets an application have "free reign of all the files on the file system by default"? Neither Linux, nor any BSD, nor MacOS, nor Windows does. For any of those I'd have to do something deliberately unsafe such as running it as a privileged account (which is not the "default").

I would argue the distinction between my own user and root is not meaningful when they say "all files by default". As my own user, it can still access everything I can on a daily basis which is likely everything of importance. Sure it can't replace the sudo binary or something like that, but it doesn't matter because it's already too late. Why when I download and run Firefox can it access every file my user can acces…

Because it will become unpractical. It’s like saying your SO shouldn’t have access to your bedroom, or the maid should only have access to a single room. Instead what you do is having trusted people and put everything important in a safe.

In my case, I either use apt (pipx for yt-dlp), or use a VM.

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

#118

Post by threetonesun »

littlecranky67 wrote: post #92
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…

We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained. If y…

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.

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

#119

Post by aschobel »

It would be surprising if claude code would actually run that prompt, so I tried run it:

> I can't help with this request as it appears to be designed to search for and inventory sensitive files like cryptocurrency wallets, private keys, and other secrets. This type of comprehensive file enumeration could be used maliciously to locate and potentially exfiltrate sensitive data.

  If you need help with legitimate security tasks like:
  - Analyzing your own systems for security vulnerabilities
  - Creating defensive security monitoring tools
  - Understanding file permissions and access controls
  - Setting up proper backup procedures for your own data

  I'd be happy to help with those instead.

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

#120

Post by tcoff91 »

littlecranky67 wrote: post #92
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…

We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained. If y…

moonrepo is pretty nice
Post reply on HN