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

Pnpm has a new setting to stave off supply chain attacks

pnpm.io

Post reply on HN
Print view View original

41–50 of 152 posts

Re: Pnpm has a new setting to stave off supply chain attacks

#41

Post by mirekrusin »

__MatrixMan__ wrote: post #40

Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to cre…

name + version are immutable, you can't republish packages in npm under existing version.

you can only unpublish.

content hash integrity is verified in lockfiles.

the problem is with dependencies using semver ranges, especially wide ones like "debug": "*"

initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates.

also not running as default / whitelisting postinstall scripts is good default in pnpm.

modifying (especially adding) keys in npmjs.org should be behind dedicated 2fa (as well as changing 2fa)

[0] https://docs.npmjs.com/generating-provenance-statements

Re: Pnpm has a new setting to stave off supply chain attacks

#42

Post by frankdejonge »

__MatrixMan__ wrote: post #40

Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to cre…

Resolving by hash is a half solution at best. Not having automated dependency upgrades also has severe security downsides. Apart from that, lock files basically already do what you describe, they contain the hashes and the resolution is based off the name while the hash ensures for the integrity of the resolved package. The problem is upgrade automation and supply chain scanning. The biggest issue there is that scanning is not done where the vulnerability is introduced because there is no money for it.

Re: Pnpm has a new setting to stave off supply chain attacks

#43

Post by mort96 »

fzeindl wrote: post #7
omnicognate wrote: post #4

Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.

ISO8601 durations should be used, like PT3M.

Oh wow, never looked at ISO8601 durations before and I had no idea they were this ugly. Please, no, don't make me deal with ISO8601. I'd rather write a number of seconds or a format like 'X weeks' or 'Y hours Z minutes'x ISO8601 looks exclusively like a data interchange format

Re: Pnpm has a new setting to stave off supply chain attacks

#44

Post by mort96 »

__MatrixMan__ wrote: post #40

Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to cre…

The problem here isn't, "someone introduced malware into an existing version of a package". The problem is, "people want to stay up to date, so when a new patch version is released, everyone upgrades to that new patch version".

Re: Pnpm has a new setting to stave off supply chain attacks

#45

Post by codemonkey-zeta »

OskarS wrote: post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

I think the surface area for bugs in a C++ dependency is way bigger than a JS one. Pulling in a new node module is not going to segfault my app, for example.

Re: Pnpm has a new setting to stave off supply chain attacks

#47

Post by patwolf »

OskarS wrote: post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

It's common to have npm auditing enabled, which means your CI/CD will force you to update to a brand new version of a package because a security vulnerability was reported in an older one.

I've also had cases where I've found a bug in a package, submitted a bug report or PR, and then immediately pulled in the new version as soon as it was fixed. Things move fast in the JavaScript/npm/GitHub ecosystem.

Re: Pnpm has a new setting to stave off supply chain attacks

#48

Post by dtech »

OskarS wrote: post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

Waiting 6 months to upgrade a dependency seems crazy, that's definitely not a thing in other languages or maybe companies. (It might be due to priorization, but not due to some rule of thumb)

In the JVM ecosystem it's quite common to have Dependabot or Renovate automatically create PRs for dependency upgrades withing a few hours of it being released. If it's manual it highly irregular and depends on the company.

Re: Pnpm has a new setting to stave off supply chain attacks

#49

Post by diegof79 »

OskarS wrote: post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

Transitive dependencies are the main issue.

Suppose you have a package P1 with version 1.0.0 that depends on D1 with version ^1.0.0. The “^” indicates a range query. Without going into semver details, it helps update D1 automatically for minor patches or non-breaking feature additions.

In your project, everything looks fine as P1 is pinned to 1.0.0. Then, you install P2 that also uses D1. A new patch version of D1 (1.0.1) was released. The package manager automatically upgrades to 1.0.1 because it matches the expression ^1.0.0, as specified by P1 and P2 authors.

This can lead to surprises. JS package managers use lock files to prevent changes during installs. However, they still change the lock file for additions or manual version upgrades, resolving to newer minor dependencies if the version range matches. This is often desirable for bug fixes and security updates. But, it opens the door to this type of attack.

To answer your question, yes, the JS ecosystem moves faster, and pkg managers make it easy to create small libraries. This results in many “small” libraries as transitive dependencies. Rewriting these libraries with your own code works for simple cases like left-pad, but you can’t rewrite a webserver or a build tool that also has many small transitive dependencies. For example, the chalk library is used by many CLI tools to show color output.

Post reply on HN