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

71–80 of 152 posts

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

#71

Post by Rockslide »

streptomycin wrote: post #64
DougBTX wrote: post #61

Earlier quoted context omitted.

> Our package-lock.json specified the stable version 1.3.2 or newer Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?

If they were for some reason doing `npm install` rather than `npm ci`, then `npm install` does update packages in the lock file. Personally I always found that confusing, and yarn/pnpm don't behave that way. I think most people do `npm ci` in CI, unless they are using CI to specifically test if `npm install` still works, which I guess maybe would be a good idea if you use npm since it doesn't like obeying the lock fi…

How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.

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

#72

Post by debazel »

__MatrixMan__ wrote: post #58
frankdejonge wrote: post #42

Earlier quoted context omitted.

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

Do you suppose that automated dependency upgrades are less likely to introduce malicious code than to remove it? They're about compliance, not security. If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". As for lock files, they prevent skulduggery after the maintainer has said "yeah, I trust this thing and my u…

> If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security".

Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.

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

#73

Post by fainpul »

cap11235 wrote: post #52
mcintyre1994 wrote: post #33

Earlier quoted context omitted.

Nice, but I think the config file is a much better implementation for protecting against supply chain attacks, particularly those targeting developers rather than runtime. You don’t want to rely on every developer passing a flag every time they install. This does suffer from the risk of using `npm install` instead of `pnpm install` though. It would also be nice to have this as a flag so you can use it on projects tha…

You can put the uv setting in pyproject.toml or uv.toml.

But then you have to hardcode a timestamp, since this is not gonna work in uv.toml:

  exclude-newer = $(date -uv -14d '+%Y-%m-%dT%H:%M:%SZ')

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

#74

Post by __MatrixMan__ »

debazel wrote: post #72
__MatrixMan__ wrote: post #58

Earlier quoted context omitted.

Do you suppose that automated dependency upgrades are less likely to introduce malicious code than to remove it? They're about compliance, not security. If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". As for lock files, they prevent skulduggery after the maintainer has said "yeah, I trust this thing and my u…

> If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.

Who is going to discover it in that time? Not the maintainers, they've already released it. Their window for scrutiny has passed.

There is some sense in giving the early adopters some time to raise the alarm and opting into late adoption, but isn't that better handled by defensive use of semantic versioning?

Consider the xzutils backdoor. It was introduced a month before it was discovered, and it was discovered by a user.

If that user had waited a few days, it would just have been discovered a few days later, during which time it may have been added to an even wider scope of downstream packages. That is, supposing they didn't apply reduced scrutiny due to their perception that it was safe due to the soak period.

Its not nothing, but its susceptible to creating a false sense of security.

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

#75

Post by philipwhiuk »

progx wrote: post #9

That solve not really the problem. A better (not perfect) solution: Every package should by AI analysed on an update before it is public available, to detect dangerous code and set a rating. In package.json should be a rating defined, when remote package is below that value it could be updated, if it is higher a warning should appear. But this will cost, but i hope, that companies like github, etc. will allow package…

A better solution is restricting package permissions.

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

#76

Post by JoshuaEN »

Ozzie_osman wrote: post #55

Does anyone understand why npm isn't adding these sorts of features?

There was an NPM RFC for this feature (though not as focused on supply chain attacks) in 2022, but the main response mirrored some of the other comments in here.

"waiting a length of time doesn’t increase security, and if such a practice became common then it would just delay discovery of vulnerabilities until after that time anyways"

https://github.com/npm/rfcs/issues/646#issuecomment-12824971...

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

#77

Post by debazel »

__MatrixMan__ wrote: post #74
debazel wrote: post #72

Earlier quoted context omitted.

> If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.

Who is going to discover it in that time? Not the maintainers, they've already released it. Their window for scrutiny has passed. There is some sense in giving the early adopters some time to raise the alarm and opting into late adoption, but isn't that better handled by defensive use of semantic versioning? Consider the xzutils backdoor. It was introduced a month before it was discovered, and it was discovered by a…

The maintainers did notice in both of the recent attacks, but it takes time to regain access to your compromised account to take the package down, contact npm, etc.

All recent attacks have also been noticed within hours of release by security companies that automatically scan all newly released packages published to npm.

So as far as I know all recent attacks would have been avoided by adding a short delay.

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

#78

Post by TheRoque »

rtpg wrote: post #35
homebrewer wrote: post #27

Earlier quoted context omitted.

The new setting is consistent with the old ones, which is more important IMHO: https://pnpm.io/settings#modulescachemaxage

the name could have included it though right?

If the others don't include it, it could be another inconsistance though

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

#79

Post by rpdillon »

progx wrote: post #17
robertlagrant wrote: post #15

Earlier quoted context omitted.

The Politician's Syllogism[0] is instructive. [0] https://en.wikipedia.org/wiki/Politician's_syllogism

OK, we are here now on reddit or facebook? I thought we discuss here problems and possible solutions. My fault.

I'm not sure why everyone is so hostile. Your idea has merit, along the lines of a heuristic that you trigger a human review as a follow-up. I'd be surprised if this isn't exactly the direction things go, although I don't think the tools will be given for free, but rather made part of the platform itself, or perhaps as an add-on service.

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

#80

Post by mort96 »

__MatrixMan__ wrote: post #54
mort96 wrote: post #44

Earlier quoted context omitted.

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".

The problem is that they implicitly do so. If they had to enter the hash of the latest and greatest version, the onus would be on them at that time to scrutinize it. At worst the spread of the malicious package would be slowed, and at best it would be stopped.

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

Post reply on HN