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.

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.

> alias npm=...

I use sandbox-run: https://github.com/sandbox-utils/sandbox-run

The above simple alias may work for node/npm, but it doesn't generalize to many other programs available on the local system, with resources that would need to be mounted into the container ...

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

Won't that still download malicious packages that are dep?

This will break native dependencies when the host platform is not the same as the container platform.

That definitely helps and worth doing. On Mac though I guess you need to move the entire development to containers due to native dependencies.

> triple-backtick code blocks

If only :(

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

All package ecosystems that allow unvetted code being published are affected, it just happens that npm is by far the most popular one, so it gets all the news.

I come from a JavaScript background, and I've got to admit that the ecosystem is designed in a way that is really prone to attack.

It is like the xz incident, except that each dependency you pull is maintained by a random guy on the internet. You have to trust every one of them to be genuine and that they won't fall into any social engineering attacks.

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.

Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.

this is one of the less talked about benefits of using bun

Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago they ended up adding downloadable builds for the most common platforms, but for anything else the expectation still was (and is, I guess) to build sources at install time.

Swift Package Manager[0] executes a Swift script. The Package.swift file[1] (the manifest) is actually an executed source file.

I assume that it's heavily sandboxed, though, so it may be difficult to leverage.

[0] https://docs.swift.org/swiftpm/documentation/packagemanagerd...

[1] https://developer.apple.com/documentation/packagedescription

pnpm v10 disables all lifecycle scripts by default and requires the user to whitelist packages.

https://github.com/orgs/pnpm/discussions/8945

> doesn't just download packages. It executes code. Specifically, it

It pains me to remember that the reason LLMs write like this is because many humans did in the training data.

Many front end tools are written in a faster language. For example, the next version of TypeScript compiler, SASS, SWC (minifier), esbuild (bundler used by Vite), Biome (formatter and linter), Oxc (linter, formatter and minifier), Turbopack (bundler), dprint (formatter), etc.

They use proinstall script to fetch pre-built binaries, or compile from source if your environment isn't directly supported.

OK but have you seen how many projects' official installation instructions are some form of curl | bash?

There is the "--ignore-scripts" option and had no issue using it for now.

One use case is downloading of binaries. For example mongo-memory-server [0] will download the mongoDB binary after you have installed it.

[0] https://www.npmjs.com/package/mongodb-memory-server

I seem to recall Husky at one point using lifecycle hooks to install the git hooks configured in your repository when running NPM install.

Notable times this has bitten me include compiling image compression tools for gulp and older versions of sass, oh and a memorable one with openssl. Downloading a npm package should ideally not also require messing around with c compilation tools.

When I published a library it got about 300 downloads a week for the first few and then dropped down to about 100. That would be a lot of weeks.

> Many of the dependencies used names that are known to be “hallucinated” by AI chatbots.

There’s more here than that.

Or it's some poor idiot's CI repeatedly downloading them, and for a zombie project that no one will ever use.

As TFA says, they're targeting package names that are somewhere in LLM training data but don't actually exist, so are being hallucinated by LLMs. And there's now a large number of folks with zero clue busy vibe-coding their killer app with no idea that bad things can happen.

I would not be surprised to find that 80%+ of those 86,000 people got pwned.

Use dependencies that are fairly popular and pick a release that's at least a year old. Done. If there was something wrong with it, someone would've found it by now. For a hobbyist, that's more than sufficient.

There are some operating systems, like FreeBSD, where you use the system’s package manager and not a million language specific package managers.

I still maintain pushing this back to library authors is the right thing to do instead of making this painful for literally millions of end-users. The friction of getting a package accepted into a critical mass of distributions is the point.

Somewhat controversial these days, but treat every single dependency as a potential security nightmare, source of bugs, problem that you will have to solve in the future. Use dependencies carefully and as a last resort.

Vendoring dependencies (copying the package code into your project rather than using the package manager to manage it) can help - it won't stop a malicious package, but it will stop a package from turning malicious.

You can also copy the code you need from a dependency into your code (with a comment giving credit and a link to the source package). This is really useful if you just need some of the stuff that the package offers, and also forces you to read and understand the package code; great practice if you're learning.

Avoid dependencies with less than 1M downloads per week. Prefer dependencies that have zero dependencies like Hono or Zod.

https://npmgraph.js.org/?q=hono

https://npmgraph.js.org/?q=zod

Recently I switched to Bun in part because many dependencies are already included (db driver, s3 client, etc) that you'd need to download with Node or Deno.

(1) Start by not using packages that have stupid dependencies

Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages. Those 2 things, a library that provides some functionality, and a CLI command that lets you use the library from the command line, SHOULD NEVER BE MIXED.

The library should be its own package without the bloat of the command line crap

(2) Choose low dependency packages

Example: commander has no dependencies, minimist now has no dependencies. Some other command line parsers used to have 10-20 dependencies.

(3) Stop using packages when you can do it yourself in 1-2 lines of JS

You don't need a package to copy files. `fs.copyFileSync` will copy a file for. `fs.cpSync` will copy a tree, `child_process.spawn` will spawn a process. You don't need some package to do these things. There's plenty of other examples where you don't need a package.

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 not only sandboxing your code, but also making your dev environments repeatable.

If you are using GitHub, use codespaces. If you are using gitlab, workspaces. If you are using neither, check out tools like UTM or Vagrant.

I'm not sure about NPM specifically, but in general: Pick a specific version and have your build system verify the known good checksum for that version. Give new packages at least 4 weeks before using them, and look at the git commits of the project, especially for lesser-known packages.

If you're on Linux, I've tried to build an easy yet secure way to isolate your system from your coding projects with containers. See https://github.com/evertheylen/probox

As 'numbsafari said below, you should no longer user your host for dev..this includes all those cool AI assistant tools. You need to containerize all the things with runpod or docker

> As a hobbyist how do I stay protected and in the loop for breaches like this?

For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe.

The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladder but not nearly as bad as the user-submitted madness outside Linux).

But it seems like your question is about front end web development, and that's not my world and I have no advice beyond sympathy.

> occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot

Pretty much that's the problem exactly. Distributing software is hard. It's a lot of work at a bunch of different levels of the process, and someone needs to commit to doing it. If you aren't willing to commit your time and resources, don't distribute it in a consumable way (obviously you can distribute what you built with it, and if it's appropriately licensed maybe someone else will come along and productize it).

NPM thought they could hack that overhead and do better, but it turns out to have been a moved-too-fast-and-broke-things situation in hindsight.

probably no:

https://github.com/evilsocket/opensnitch/discussions/1290

that malware campaign is still active.

Any string can be typosquatted unfortunately.

One option to make it a little safer is to add ignore-scripts=true to a .npmrc file in your project root. Lifestyle scripts then won't run automatically. It's not as nice as Pnpm or Bun, though, since this also prevents your own postinstall scripts from running (not just those of dependencies), and there's no way to whitelist trusted packages.

You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.

Now you have the opposite problem, where a vulnerability could be found in one of your dependencies but you don't get the fix until the next "normal time that you verify that your program actually needs the update".

So, vendoring?

Well in the Java world, Maven had custom repositories which did this for the last 20+ years.

You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.

That is exactly what I do.

Because then I would have to test, write, and maintain that code—and it becomes susceptible to leaky abstractions!

I’ve wondered this for so long, I questioned my own sanity.

There's nothing really specially about the JS ecosystem that creates this problem. Plenty of others could fall in the same way, including C++ (see xz).

The problem is we've been coasting on an era where blind trust was good enough an programming was niche enough.

Eh sometimes it's pypi