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

151–160 of 460 posts

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

#151

Post by pharrington »

cedws wrote: post #65
coldpie wrote: 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…

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

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

#152

Post by pharrington »

cedws wrote: post #108
exDM69 wrote: post #91

Earlier quoted context omitted.

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.

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.

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

#153

Post by evertheylen »

vorgol wrote: post #20

OSs need to stop letting applications have a free reign of all the files on the file system by default. Some apps come with apparmor/selinux profiles and firejail is also a solution. But the UX needs to change.

If you are on Linux, I'm writing a little tool to securely isolate projects from eachother with podman: https://github.com/evertheylen/probox. The UX is an important aspect which I've spent quite some time on.

I use it all the time, but I'm still looking for people to review its security.

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

#154

Post by tremon »

chuckadams wrote: post #104
wat10000 wrote: post #34

Earlier quoted context omitted.

Part of the value proposition for bringing in outside libraries was: when they improve it, you get that automatically. Now the threat is: when they “improve” it, you get that automatically. left-pad should have been a major wake up call. Instead, the lesson people took away from it seems to have mostly been, “haha, look at those idiots pulling in an entire dependency for ten lines of code. I, on the other hand, am in…

So, what's the acceptable LOC count threshold for using a library? Maybe scolding and mocking people isn't a very effective security posture after all.

Scolding and mocking is all we're left with, since two decades worth of rational arguments against these types of hazards have been dismissed as fear-mongering.

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

#156

Post by threetonesun »

crabmusket wrote: post #144
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.

I'd recommend pnpm over npm for monorepos. Forcing you to be explicit about each package's dependencies is good. I found npm's workspace features lacking in comparison and sparsely documented. It was also hard to find advice on the internet. I got the sense nobody was using npm workspaces for anything other than beginner articles.

In the context of what we're talking about here, using the default package manger to install a different package manger as a dependency has never quite sat right with me.

And npm workspaces is certainly "lacking features" compared to NX, but in terms of making `npm link` for local packages easier and running scripts across packages it does fine.

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

#157

Post by pdw »

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.

Right, people forget that the xz-utils backdoor happened to a very traditional no-dependencies C project.

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

#158

Post by abuob »

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…

Shameless self-plug and probably not what you're looking for, but anyway: I've created https://github.com/abuob/yanice for that sort of monorepo-size; too many applications/libraries to be able to always run full builds, but still not google-scale or similar.

It ultimately started as a small project because I got fed up with NX' antics a few years back (I think since then they improved quite a lot though), I don't need caching, I don't need their cloud, I don't need their highly opinionated approach on how to structure a monorepository; all I needed was decent change-detection to detect which project changed between the working-tree and a given commit. I've now since added support to enforce module-boundaries as it's definitely a must on a monorepo.

In case anyone wants to try it out - would certainly appreciate feedback!

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

#159

Post by skydhash »

willsmith72 wrote: post #148
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.

sounds like the best way to miss critical security upgrades

That’s why most mature (as in disciplined) projects have a rss feed or a mailing list. So you know when there’s a security bug and what to do about it.

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

#160

Post by chrisweekly »

tiagod wrote: post #143
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…

Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.

pnpm is not only more secure, it's also faster, more efficient wrt disk usage, and more deterministic by design.
Post reply on HN