When people ask me what's so wrong with lowering the bar of entry for engineering, I point to things like this.
Engineering used as a title should be regulated in the software industry; it was always a title reserved for a role that requires accountability. In software, it became used so casually without legal restriction that full stack developers started using it.
NPM flooded with malicious packages downloaded more than 86k times
251–260 of 308 posts
Re: NPM flooded with malicious packages downloaded more than 86k times
#252Earlier 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.
And those last two points have absolutely nothing to do with micro dependencies one way or the other.
Re: NPM flooded with malicious packages downloaded more than 86k times
#253Earlier quoted context omitted.
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
#254Here'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/
Re: NPM flooded with malicious packages downloaded more than 86k times
#255Here'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/
Doesn't Docker run as `root` by default, and alter the permission of your folder by taking ownership and making it as `root:root` ?
Re: NPM flooded with malicious packages downloaded more than 86k times
#256Earlier quoted context omitted.
Don't do development on your local machine. Full stop. Just don't. Do development, all of it, inside VMs or containers, either local or remote. Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling. This has the added benefit of…
Are people actually using UTM to do local development? Im genuinely curious because I casually looked into it so that i could work on some hobby stuff over lunch on my work machine. However I just assumed the performance wouldn't be too great. Would love to hear how people are setup…
There's around 10-15% performance penalty for VMs (assuming you use arm64 guests), but the whole system is just so much faster and well built than anything Intel-based to day, that it more than compensates.
For Windows, it's lacking accelerated video drivers, but VMWare Fusion is an ok free alternative - I can totally play AAA games from last decade. Enjoy it until broadcom kills it.
Re: NPM flooded with malicious packages downloaded more than 86k times
#257Here'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/
Not sure how secure this really is, because it's fairly easy to break out of a Docker container with the default settings (due to the fact that the kernel is shared between containers and the host, unlike with VMs). Rootless Docker (or better, Podman) would improve security greatly.
Re: NPM flooded with malicious packages downloaded more than 86k times
#258Here'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 foll…
Improving NPM's processes, having more companies auditing packages, changing the way NPM the tool works - that's all good but far from enough, it doesn't actually address the root vulnerability, which is that we're way too comfortable running other people's arbitrary code.
Containerization and strict permissions system by default seem to be where we're headed.
Re: NPM flooded with malicious packages downloaded more than 86k times
#259Earlier quoted context omitted.
Oh man you pick the one other language that followed the JavaScript model?! How about C, Java, Go, Lisp, C#, C++, D… and new ones like Odin that are explicitly against package managers for this very reason.
When you start writing with C, where do you get your stdio.h file? Do you write it yourself, or inspect it line by line every time or do you trust the installation package you just ran?
Re: NPM flooded with malicious packages downloaded more than 86k times
#260Earlier quoted context omitted.
> 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?
As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.