Live data from Hacker News

'No way to prevent this,' says only package manager where this regularly happens

kevinpatel.xyz

61–70 of 230 posts

Re: 'No way to prevent this,' says only package manager where this regularly happens

#61
post #56
post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

There is also not too much legitimacy to the fact that Rust packages can run unsandboxed when they build themselves.

I feel like it's harder to hide malicious stuff in Rust build scripts.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#62

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but i…

What important functionality do you feel is missing from the commonly used JS environments (node and browser) that is causing people to install it as a third party dependency?

The issue isn’t that the functionality doesn’t exist, it’s always backwards compatibility with versions where it did not yet exist.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#64
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't.

Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)

How to set them up?

- use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security

- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, I’m the maintainer)

- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally

All are open source / free.

If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.

Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so. In the past few weeks, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)

Re: 'No way to prevent this,' says only package manager where this regularly happens

#66

Earlier quoted context omitted.

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but i…

Why Python, tho, in that case? Its stdlib is quite robust. Surprisingly so in some areas.

I'm not convinced that Python should be the standard for package management either. Earlier this week I was trying to publish a Python package for the first time wrapping a Rust library I wrote (for use only on Linux and Python 3.12+), and it literally took me hours to get from "I have a wheel that I can import and it works on my system" to "I have published that wheel and can install the package from PyPI on the set of systems that I'm trying to support and it actually works". Everything I've heard about this indicates that the situation for Python packaging is literally better than it ever has been before with the current tooling, so I can't even imagine how bad it was for the decades before. In comparison, having literally never touched npm before, I was able to publish a wrapper around the same library and validate that it was working in maybe 10 minutes (most of which were spent from not realizing that a certain tool was failing with a vague "file not found" error because I hadn't installed npm yet).

I'm not saying that npm is doing everything right, but I suspect that beyond the obvious low-hanging fruit that we hear about pretty consistently with npm there's probably a long tail of less obvious stuff that can be exploited that will not be specific to npm. The fundamental problems with supply-chain vulnerabilities aren't going to go away if npm magically became pip or go modules overnight.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#67
post #55

Earlier quoted context omitted.

Just dont use npm. Use a package manager which doesn't execute postinstall by default. The switch is incredibly simple.

Which package manager is that, and what caveats does it offer?

Pnpm - installs are faster to boot. We haven’t missed anything

Re: 'No way to prevent this,' says only package manager where this regularly happens

#68
post #55

Earlier quoted context omitted.

Just dont use npm. Use a package manager which doesn't execute postinstall by default. The switch is incredibly simple.

Which package manager is that, and what caveats does it offer?

pnpm

Re: 'No way to prevent this,' says only package manager where this regularly happens

#69
I use C++ and Conan with my own recipes and pre-built artifacts.

This mitigates things to a great extent.

I do not know who thought that having your dependencies depend on the internet with a zillion users doing stuff to each package was a good idea for enterprise environments...

It is crazy how much things can get endangered this way.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#70
No surprise here. That's what you get when you have a language/ecosystem where core devs refuse to fix fundamental flaws, cuz for them breaking backwards compatibility is the worse crime that can ever be committed. And so all that happens in JS-land will eternally be layering lipstick on the pig in the cesspool. Too afraid of going through something similar to the Python 2 -> 3 fiasco, I guess because too many web devs and site admins would be incensed at being forced to fix their broken universe; as if it isn't already broken in its current condition.
Post reply on HN