Live data from Hacker News

Malicious versions of Nx and some supporting plugins were published

github.com

431–440 of 460 posts

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

#431

Earlier quoted context omitted.

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

I work for a company that needs to ship software so my salary can get paid

Can't you guys replace the most vulnerable parts with something better? I have been experimenting with Go + Fyne, it is pretty neat, all things considered.

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

#432
post #356

Earlier quoted context omitted.

Not "instead", it's "in addition to". Your classical defense-in-depth.

No, "instead". If they compromise bubblewrap to send out your files, and you run bubblewrap anyway for any reason, you're still compromised. But obviously you can probably safely pin bubblewrap to a given version, and you don't need to "install packages through it", which is the main weakness of package managers

Bubblewrap uses the same Linux functions that billion dollar cloud infrastructure use. Bubblewrap does no sandboxing/restrictions itself, it's instructing the kernel to do it.

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

#433

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…

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…

Not if you make podman your default way of isolating projects.

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

#434
post #241

Earlier quoted context omitted.

I agree with you that VMs would provide better isolation. But I do think containers (or other kernel techniques like SELinux) can still provide quite decent isolation with a very limited performance/ease-of-use cost. Much better than nothing I'd say?

I would kinda disagree with this. The whole 'better than nothing' is what gave a huge chunk of people a false sense of security wrt containers to begin with. The reality is that there is no singular create_container(2). Much of the 'security' is left up to the runtime of choice and the various flags they choose or don't choose to enable. Others in this thread have already mentioned both bubblewrap and podman. The fac…

It’s a gradient. An airgapped physical device is better than a VM. A VM is better than podman. Podman is better than nothing.

A locked door is better than an unlocked one, even if it gives its owner a false sense of security. There is still non-zero utility there.

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

#435

Earlier quoted context omitted.

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?

Conceivably couldn’t a post install script be used for the malicious dependency to install its own instance of Claude code (or similar tool)? In which case you couldn’t really separate your dev environment from a hostile LLM.

I run npm in the container, too, along with my dev tooling. They’d have to break out of the container, which I’m sure is possible, but is a good bit harder than just running an arbitrary nom script.

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

#436

Any practical tips for hardened security when programming? Don't want to be exposed to npm/pip/cargo installing password/browser cookie stealers. What worries me is the little to no isolation between the dev environment and the rest of the OS for day to day use.

Use as few deps as possible, and run your projects in containers, or even better, VMs.

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

#437
post #254

Just a normal day in Javascript land. laughs in elixir

It’s not like Hex has some magical way of only downloading non-malicious packages.

If Hex gets popular enough, it will happen there, too. Even if the install process doesn’t run arbitrary code, when you actually load the library, it can do stuff, so I don’t see any reason to gloat.

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

#438

Earlier quoted context omitted.

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.

Yes, I've found the experience of getting pnpm quite irritating/confusing. Corepack doesn't seem to work the way I would want it to, either.

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

#439

Earlier quoted context omitted.

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.

After 10 years or so enduring the endless cycle of "new thing to replace npm", I'm using: npm. And I'm not creating monorepos.

I was happily using npm until I outgrew it. pnpm seemed the smallest step towards what I needed after having evaluated nx, moonrepo etc.

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

#440

Earlier quoted context omitted.

No, "instead". If they compromise bubblewrap to send out your files, and you run bubblewrap anyway for any reason, you're still compromised. But obviously you can probably safely pin bubblewrap to a given version, and you don't need to "install packages through it", which is the main weakness of package managers

How? bubblewrap isn't something someone has randomly uploaded to npm, it has well known maintainers and a well organised release process (including package signing). Which is easier to do: upload a package to npm and get people to use it, or spend 2+ years trying to become a maintainer of bubblewrap or one of its dependencies to compromise it.

Sure, but there's plenty of packages with well-known maintainers who get compromised...
Post reply on HN