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

Show HN: Safe-NPM – only install packages that are +90 days old

github.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Show HN: Safe-NPM – only install packages that are +90 days old

#24

Post by 2muchcoffeeman »

moritzwarhier wrote: post #9

As someotherguyy already mentioned, this is a default feature in pnpm. And as far as cat-and-mouse-games go in other package managers, I'd say that pinning dependencies and disabling postinstall scripts is a much better option. Sure, not a foolproof one either, but as good as it gets. edit: misspelled someotherguyy's user name

Why is the community persisting with such poor solutions?

Re: Show HN: Safe-NPM – only install packages that are +90 days old

#25

Post by [deleted] »

lelandbatey wrote: post #18
ttoinou wrote: post #17

If everybody does that, won't we take 90 days more to detect problems / hacks of npm packages ?

No, cause the folks detecting the problems typically do so by actively scanning new releases (usually security companies do this). Few such problems are detected by people who do a "normal" update and receive compromised code, investigate, and then report the problem. It does happen, but it's not the "usual" way these supply chain attacks are discovered, especially not the really big ones.

[deleted]

Re: Show HN: Safe-NPM – only install packages that are +90 days old

#26

Post by zelphirkalt »

This works only if there are some other people, who will use a dependency "too early" to fall victim to some exploit and then notice it, within those 90 days. Imagine, if everyone only used packages older than 90 days. Then we would have no frontrunner to run into the issues before us.

A cooldown time alone is not actually a sufficient solution. What people really need to stop doing, is not properly pinning their versions and checksums, and installing whatever newer version is available. That would cause a problem even, if the date line is moved 90 days into the future for all packages. If however, one only updates versions of dependencies when one consciously makes that choice, there are far fewer points in time, when versions change, and therefore the chance of catching something is also much lower. Combine that with a cooldown time/minimum age for versions, and you got an approach.

Re: Show HN: Safe-NPM – only install packages that are +90 days old

#27

Post by zelphirkalt »

tkzed49 wrote: post #5

Not controlling transitive deps makes this vastly less useful because direct deps can specify version ranges (e.g. latest minor version). Personally I'd stick with pnpm's feature.

This is why one should pin all direct and transitive dependencies with their checksums and not upgrade everyday willy-nilly. There is no need to specify the specific version numbers of transitive dependencies, if one keeps a lock file that pins those exact versions and checksums of transitive dependencies, and one doesn't upgrade willy-nilly all the time. Make upgrading dependencies a conscious choice, and perhaps have a policy of at most upgrading every X days.

Re: Show HN: Safe-NPM – only install packages that are +90 days old

#29

Post by moritzwarhier »

2muchcoffeeman wrote: post #24
moritzwarhier wrote: post #9

As someotherguyy already mentioned, this is a default feature in pnpm. And as far as cat-and-mouse-games go in other package managers, I'd say that pinning dependencies and disabling postinstall scripts is a much better option. Sure, not a foolproof one either, but as good as it gets. edit: misspelled someotherguyy's user name

Why is the community persisting with such poor solutions?

What would be a better solution? Do other package managers reliably restrict access to the host system beyond the scope of the project folder?

Many quirks come from abilities that were once deemed useful, such as compiling code in other languages after package install.

Sure, today, I can disable install scripts if I want but it doesn't change much when I eventually run code from the package anyway.

But even restricting access to the file system to the project's root folder would leave many doors open, with or without foreign languages: Node is designed as a general purpose JS runtime, including server-side and build-time usage.

The utility of node.js was initially to provide a JS API that, unlike the web platform, is not sandboxed. And npm is the default package manager.

This not only allows server-side usage, but also is essential to many early dev scenarios. Back in the days, it might have been SCSS builds using node-gyp (wouldn't recommend). Today it's things like Golang TypeScript or SSGs.

So, long story short: as many people before me already said, it's an ecosystem/cultural problem.

One thing against npm in this regard was/is its broken lock-file handling until I think version 12 or 16. That led to unintended transitive dependency version changes, breaking any reproducibility.

Same for compiling foreign languages.

These problems are solved today / not different from other package managers and -registries, as far as I know.

The culture of taking breaking changes and dependency bloat lightly has not changed as much, I think, although it's improved.

This most important point seems to be related to 3 reasons IMO:

- junior developers without experience in library development reaching large audiences

- specs, languages, runtime, and the package managers itself going through disruptions and evolutions

- rapidly releasing breaking majors, often caused by the above factors

The combination of these plus the role of the project lead/team who actually decides about the dependencies.

There are probably also many projects with unclear roles and many people who can push manifest changes, coupled with habitual access to CI/CD pipelines.

Post reply on HN