Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

Post reply on HN
Print view View original

191–200 of 308 posts

Re: NPM flooded with malicious packages downloaded more than 86k times

#191

Post by immibis »

klabb3 wrote: post #168
socalgal2 wrote: post #111

Earlier quoted context omitted.

It's no different anywhere else. I just downloaded jj (rust), it installed 470+ packages When I downloaded wan2gp (python) it installed it install 211 packages.

> It's no different anywhere else. But it is. Both C/C++ and Go are not at all like this. I don’t know about Python but Rust ecosystem tends attract enthusiasts who make good single purpose packages but that are abandoned because maintainers move on, or sometimes forked due to minor disagreements similar to how Linux/unix is fragmented with tribal feuds.

Go is like this...

Re: NPM flooded with malicious packages downloaded more than 86k times

#192

Post by immibis »

codedokode wrote: post #155
scuff3d wrote: post #140

Earlier quoted context omitted.

One of the biggest things that pushes me away from Rust is the reliance on micro dependencies. It's a terrible model.

What's wrong with micro dependencies? Isn't it better to download only the code you need? Also it makes refactoring easier, and enforces better architecture.

https://thecodelesscode.com/case/119

Re: NPM flooded with malicious packages downloaded more than 86k times

#193

Post by immibis »

codedokode wrote: post #157
lenkite wrote: post #151

Earlier quoted context omitted.

Believe such build tools and processes should be run inside a container environment. Maybe once all OS have native, cheap and lean containers and permit dead simple container execution of scripts, this will be possible.

Google's OS, Android, has sandboxes. It's some Linux problem that they do not want to backport it.

It just has Linux user IDs. They're in every Linux.

Re: NPM flooded with malicious packages downloaded more than 86k times

#194

Post by codedokode »

immibis wrote: post #193
codedokode wrote: post #157

Earlier quoted context omitted.

Google's OS, Android, has sandboxes. It's some Linux problem that they do not want to backport it.

It just has Linux user IDs. They're in every Linux.

I think that was long time ago, because this doesn't allow to request permissions in runtime.

Re: NPM flooded with malicious packages downloaded more than 86k times

#195

Post by dns_snek »

ashishb wrote: post #58

Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/

This folk-wisdom scapegoating of post-install scripts needs to stop or people are going to get really hurt by the false sense of security it's creating. I can see the reasoning behind this, I really do, it sounds convincing but it's only half the story.

If you want to protect your machine from malicious dependencies you must run everything in a sandbox all the time, not just during the installation phase. If you follow that advice then disabling post-install scripts is pointless.

The supply chain world is getting more dangerous by the minute and it feels like I'm watching a train derail in slow motion with more and more people buying into the idea that they're safe if they just disable post-install scripts. It's all going to blow up in our collective faces sooner or later.

Re: NPM flooded with malicious packages downloaded more than 86k times

#196

Post by rwmj »

codedokode wrote: post #155
scuff3d wrote: post #140

Earlier quoted context omitted.

One of the biggest things that pushes me away from Rust is the reliance on micro dependencies. It's a terrible model.

What's wrong with micro dependencies? Isn't it better to download only the code you need? Also it makes refactoring easier, and enforces better architecture.

They should just be part of the stdlib of the language.

Re: NPM flooded with malicious packages downloaded more than 86k times

#197

Post by azangru »

ashishb wrote: post #76
phiresky wrote: post #68

Earlier quoted context omitted.

That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.

> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run. Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier? - Switch all projects to `pnpm`? That means switching CI, and deployment processes as well - Change the way *you* run `npm` on your machine and let your colleagues know to do the same I find the second…

> which one is easier?

> Switch all projects to `pnpm`?

Sorry; I am out of touch. Does pnpm not have these security problems? Do they only exist for npm?

Re: NPM flooded with malicious packages downloaded more than 86k times

#198

Post by dns_snek »

ashishb wrote: post #122
bitbasher wrote: post #100

Earlier quoted context omitted.

There are so many vectors for this attack to piggyback off from. If I had malicious intentions, I would probably typo squat popular plugins/lsps that will execute code automatically when their editor runs. A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via…

> A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via a docker command. Running `npm` inside Docker does not solve this problem. However, running `npm` inside Docker does not make this problem worse either. That's why I said running `npm` inside Docker redu…

I think this approach is harmful because it gives people a false sense of security and makes them complacent by making them feel like they're "doing something about it even if it's not perfect". It's like putting on 5 different sets of locks and bolts on your front door while leaving the back door unlocked and wide open during the night.

Re: NPM flooded with malicious packages downloaded more than 86k times

#199

Post by azangru »

ab_testing wrote: post #108

Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the…

> As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else.

Oh, absolutely, there is no question about it. Fewer dependencies means less headache; and if you can get the number of your dependencies to zero, then you have won the internet.

Re: NPM flooded with malicious packages downloaded more than 86k times

#200

Post by wongarsu »

rwmj wrote: post #196
codedokode wrote: post #155

Earlier quoted context omitted.

What's wrong with micro dependencies? Isn't it better to download only the code you need? Also it makes refactoring easier, and enforces better architecture.

They should just be part of the stdlib of the language.

Rust has a really big and comprehensive stdlib, especially compared to languages like C or JavaScript. It just decided that certain things won't be solved in the standard lib because there is no obviously-right solution and evolving towards a good solution is much easier in packages than in the stdlib, because the stdlib isn't versioned.

Some of the gaps feel huge, like no random, no time/date handling, and no async runtime. But but for most of them there are canonical packages that 95% of the ecosystem uses, with a huge amount of eyeballs on them. And sometimes a better solution does emerge, like jiff slowly replacing chrono and time for time/date handling.

Obviously this isn't the best solution from a security perspective. There would be less potential for supply chain attacks if everything was in the standard library. But that has to be weighed against the long-term usability of the language

Post reply on HN