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
Malicious versions of Nx and some supporting plugins were published
431–440 of 460 posts
Re: Malicious versions of Nx and some supporting plugins were published
#432Earlier 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
Re: Malicious versions of Nx and some supporting plugins were published
#433Before 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…
Re: Malicious versions of Nx and some supporting plugins were published
#434Earlier 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…
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
#435Earlier 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.
Re: Malicious versions of Nx and some supporting plugins were published
#436Any 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.
Re: Malicious versions of Nx and some supporting plugins were published
#437Just a normal day in Javascript land. laughs in elixir
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
#438Earlier 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.
Re: Malicious versions of Nx and some supporting plugins were published
#439Earlier 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.
Re: Malicious versions of Nx and some supporting plugins were published
#440Earlier 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.