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

41–50 of 69 posts

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

#41

Post by tkzed49 »

zelphirkalt wrote: post #27
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 ha…

I don't think it's accurate to envision that the average team using the npm ecosystem is upgrading their dependencies daily. Rather, the problem is that modifying your direct deps (e.g. adding a package, upgrading a package) requires modifying transitive deps.

So yeah, ~everyone is using a lockfile with checksums. But even if I think really hard about installing XYZ@1.2.3 package, and check that the lockfile diff is reasonable, I'm not manually auditing the whole supply chain (I'd get fired for getting nothing done). And a single dependency change that I choose to make can affect a substantial number of transitive deps.

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

#42

Post by mikeweiss »

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.

Umm... Tell me how the most recent supply chain attack was discovered again?

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

#43

Post by solumunus »

catlifeonmars wrote: post #40
arrty88 wrote: post #21

With the help of AI, i see no reason to install most deps nowadays besides types and react and mui framework. Everything can be built from scratch quickly.

Now you have shifted your supply chain issues to your coding agent.

And do you think the severity of the issue is anywhere near the same?

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

#46

Post by mort96 »

sebmellen wrote: post #20

"Here, install my new 1-day old NPM package that doesn't let you install packages younger than 90 days." Pardon me, I couldn’t help myself :D

I get that it's a joke, but I feel the need to defend this project anyway.

The problem with NPM isn't any one young package. The problem with the NPM is that any time you run 'npm install', you download potentially thousands of packages, and you get the most recent patch release from all of them. Installing one 1-day-old NPM package to forever avoid day 1 releases of thousands of packages seems like a worthwhile trade.

Still, I would maybe choose the tried and true PNPM instead, which supports this too.

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

#47

Post by zelphirkalt »

tkzed49 wrote: post #41
zelphirkalt wrote: post #27

Earlier quoted context omitted.

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 ha…

I don't think it's accurate to envision that the average team using the npm ecosystem is upgrading their dependencies daily. Rather, the problem is that modifying your direct deps (e.g. adding a package, upgrading a package) requires modifying transitive deps. So yeah, ~everyone is using a lockfile with checksums. But even if I think really hard about installing XYZ@1.2.3 package, and check that the lockfile diff is…

My idea is, that they do _not_ upgrade their dependencies daily, because that is what is causing the issue. People don't pin all their versions and checksums properly, and the next time they run `npm install` they get a new version of some library. I don't even want to see any "@^1.2" or whatever the syntax was. Also they should be running `npm ci`.

I have seen this multiple times with people from various backgrounds and in frontend as well as backend. People still think like "Lets auto upgrade patch releases, so that we always get the bugfixes." or "Lets upgrade quickly, so that we deal with changes right away, before accumulating the work.". But they don't think properly about security and reproducibility.

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

#49

Post by m4rtink »

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

Earlier quoted context omitted.

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 restricti…

Established Linux distributions.

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

#50

Post by zelphirkalt »

solumunus wrote: post #43
catlifeonmars wrote: post #40

Earlier quoted context omitted.

Now you have shifted your supply chain issues to your coding agent.

And do you think the severity of the issue is anywhere near the same?

I think this will remain to be seen. Wasn't there a paper linked here on HN recently, that claimed, that even few examples are sufficient, to poison LLMs? (I didn't read that paper, and merely interpreted the meaning of the title.)
Post reply on HN