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

121–130 of 152 posts

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

#121

Post by dwoldrich »

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to upgrade will mostly keep me safe.

To achieve my goal, would this approach work:

- Pin all of my package.json versions (no prefacing versions with ~ or ^)

- Routine installation of packages both on my local and on CI servers will be done using `npm ci`

- `npm install --save-exact/--save-dev` would be used only at the time of adding a package to package.json, followed by an `npm ci`

- Rely on tooling like GitHub Dependabot and CodeQL to inform the team when a dependency should be updated for security reasons and then manually update only the dependency with the desired version using `npm install lodash@4.17.21 --save-exact`, for example

EDIT: Thinking about this more, we would have to forbid deleting the package-lock.json and regenerating it with `npm install` and forbid the use of `npm update` so that package-lock.json would stay stable.

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

#122

Post by sedatk »

dwoldrich wrote: post #121

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to…

It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.

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

#123

Post by mort96 »

__MatrixMan__ wrote: post #102
mort96 wrote: post #80

Earlier quoted context omitted.

Surely you'd achieve the same thing by making people manually enter a new version number? I'm not inherently against the idea of specifying a hash, it would protect against NPM hosting infrastructure being compromised, but again, that's not what we're seeing here

If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked. But if we both attempt to install 0x456def, it's clear that whoever has 0xabc123 is in trouble. This is especially important in cases where you might need a package while you're on a separ…

> If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked.

If this happens, then either the NPM registry has been compromised or my system's 'npm' program or your system's 'npm' program has been compromised.

If the discrepancy is due to one of us running a malicious 'npm', then that malicious 'npm' CLI program could've just not flagged the signature mismatch, so specifying a hash doesn't help us anything.

If both of us are using a non-compromised 'npm' program, and the NPM registry isn't compromised, then we will never be in a situation where my "fooapp version 7.8.9" and your "fooapp version 7.8.9" differs. If a malicious actor compromises an account with publish access for the fooapp package, then all the malicious actor can do is publish a new "fooapp version 7.8.10" that has malware. That's what has happened in every single one of these high profile NPM hacks. You can't retroactively change old versions of your own packages. So to protect against this kind of attack (which, again, means every single NPM hack to date), just not auto-upgrading between minor versions is enough.

To protect against a compromised NPM registry, I agree that we should have package checksums living in our git repositories. But NPM already has that: the package-lock.json contains checksums. I don't understand what it would give us to have that checksum in the package.json instead of the package-lock.json.

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

#124

Post by mort96 »

johanyc wrote: post #95
mort96 wrote: post #43

Earlier quoted context omitted.

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

https://docs.digi.com/resources/documentation/digidocs/90001... It's pretty simple actually. > 'X weeks' or 'Y hours Z minutes' PxW, PTyHzM. So simple that I learned it in a few seconds.

I learned it too. It's just ugly. Before I looked at the relevant section of the ISO 8601 duration format yesterday, I didn't know it. After I looked at it, I now know it, and I strongly dislike it.

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

#125

Post by dwoldrich »

sedatk wrote: post #122
dwoldrich wrote: post #121

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to…

It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.

Could that just be the cost of doing business though? I think of it like when a version of Node goes out of support and you have to upgrade a bunch of stuff and fix build scripts. It's always ends up being days of work upgrading dependencies and re-testing everything.

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

#126

Post by null_deref »

sedatk wrote: post #122
dwoldrich wrote: post #121

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to…

It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.

In a case of a package breaking compatibility (^) won’t help as well.

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

#127

Post by stevepike »

sedatk wrote: post #122
dwoldrich wrote: post #121

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to…

It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.

This is very true. It can be a real fire drill if it turns out you need to go up a major version in some other dependency in order to get a security fix. It can get even worse in JS if you're on some abandoned package that's pinned to an old version of some transient dependency which turns out to be vulnerable. Then you're scrambling to migrate to some alternate package with no clear upgrade path.

On the flipside sometimes you get lucky and being on an old version of a package means you don't have the vulnerability in the first place.

libyear is a helpful metric for tracking how much of this debt you might have.

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

#128

Post by davidpfarrell »

acdha wrote: post #51
postepowanieadm wrote: post #2

If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.

Think about how the three major recent incidents were caught: not by individual users installing packages but by security companies running automated scans on new uploads flagging things for audits. This would work quite well in that model, and it’s cheap in many cases where there isn’t a burning need to install something which just came out.

Wow so couldn't said security co's establish their own registry that we could point to instead and packages would only get updated after they reviewed and approved them?

I mean I'd prolly be okay paying yearly fee for access to such a registry.

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

#129

Post by Sammi »

sedatk wrote: post #122
dwoldrich wrote: post #121

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to…

It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.

My happy middle ground solution that I've been practicing for years is to update all packages every 2 to 4 months.

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

#130

Post by mirekrusin »

__MatrixMan__ wrote: post #53
mirekrusin wrote: post #41

Earlier quoted context omitted.

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

Those are promises that npm intends to keep, but whether they do or not isn't something that you as a package user can verify. Plus there's also the possibility that the server you got those bits from was merely masquerading as npm. The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.

...which are already present in lockfiles, available in registry ie. https://registry.npmjs.org/debug etc. - it's not a problem.
Post reply on HN