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

131–140 of 152 posts

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

#131

Post by brewmarche »

1oooqooq wrote: post #56
zokier wrote: post #5

Earlier quoted context omitted.

Or just use ISO8601 standard notation (e.g. "P1D" for one day)

or PT1400M or P0.5DT700M? oh, you can use commas too. and if you're still not thinking this is fun, here's a quote from Wikipedia "But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time." just add a unit to your period parameters. sigh.

Maybe surprising for days (could also happen with minutes because of leap seconds technically :-) but for months and years this is more apparent due to month ends and leap years.

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

#132

Post by bamboozled »

cluckindan wrote: post #96
bamboozled wrote: post #46

Can anyone tell me if yarn just as vulnerable as NPM? Isn't it the packages that are vulnerable and not the package manger software itself?

No, the ”vulnerability” here is npm unilaterally allowing postinstall scripts, which are then used as an entry point for malware. Of course, the malware could just embed itself as an IIFE and get launched when the package is loaded, so disallowing postinstall is not really a security solution.

Interesting, thanks, it contradicts what was said on another similar post.

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

#133

Post by dwoldrich »

stevepike wrote: post #127
sedatk wrote: post #122

Earlier quoted context omitted.

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

I have been in the position of having a mix of having to contend with very old (4+ year) transient dependencies brought in by contemporary dependencies where npm and node versions complain about deprecations and associated security issues. I get into icky package.json `overrides` to force these transient dependencies to upgrade.

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

#134

Post by chr15m »

kibwen wrote: post #59
chr15m wrote: post #50

The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.

The downside of this approach is that this is how you create an ecosystem where legitimate security fixes never end up getting applied. There's no free lunch, you need to decide whether you're more concerned about vulnerabilities intentional backdoors (and thus never update anything automatically) or vulnerabilities from ordinary unintentional bugs (and thus have a mechanism for getting security updates automatically…

Yep. I'm calling it. The churn is more dangerous and fragile than the rot.

Two alternatives:

- The occasional alert from `npm audit` that you have to carefully, deliberately, and thoughtfully upgrade your way out of.

- The shifting sands of 100s or 1000s of towering deps that change literally every time you `pnmp install`.

The second one is the current situation and it is madness.

There should be no package lock because package.json should be the package lock.

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

#135

Post by chr15m »

JoshuaEN wrote: post #83
chr15m wrote: post #50

The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.

I don't think this is realistic in the default npm ecosystem where projects can have 1000s of dependencies (with the majority being transitive with fuzzy versions). Though pnpm does have a setting to help with this too: https://pnpm.io/settings#resolutionmode time-based, which effectively pins subdependencies based on the published time of the direct dependency.

Thousands of dependencies is exactly why you need to do this. It's fragile and dangerous to have thousands of possible changes in your software every time you `pnpm install`.

Thank you, I'll check it that setting!

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

#136

Post by kelnos »

kjok wrote: post #93
anematode wrote: post #3

Earlier quoted context omitted.

A lot of people will still use npm, so they'll be the canaries in the coal mine :) More seriously, automated scanners seem to do a good job already of finding malicious packages. It's a wonder that npm themselves haven't already deployed an automated countermeasure.

> automated scanners seem to do a good job already of finding malicious packages. That's not true. This latest incident was detected by an individual researcher, just like many similar attacks in the past. Time and again, it's been people who flagged these issues, later reported to security startups, not automated tools. Don't fall for the PR spin. If automated scanning were truly effective, we'd see deployments acro…

> This latest incident was detected by an individual researcher

So that still seems fine? Presumably researchers are focusing on latest releases, and so their work would not be impacted by other people using this new pnpm option.

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

#137

Post by chr15m »

esafak wrote: post #82
chr15m wrote: post #50

The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.

No, it isn't. Upgrades should be routine, like exercising. With your approach it becomes increasingly difficult and eventually impossible to upgrade anything since it requires moving a mountain. An update a ̶d̶a̶y̶ week makes the tech debt go away.

The reason upgrades have become routine is because modern software is slop.

We should strive for software to do one thing well (or at least be made up of modular parts that do one thing well) and prize backwards compatability, so that it does not require constant churn.

The sane middle ground between "constant upgrades" and "never upgrade" is to upgrade when there is an actual vulnerability found in a dependency. Instead of churn for no reason, you update only with a good reason.

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

#138

Post by getcrunk »

davidpfarrell wrote: post #128
acdha wrote: post #51

Earlier quoted context omitted.

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.

I think it would be a no brainer for npm to offer this but idk why they haven’t

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

#139

Post by paulhodge »

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.

solution: add your entire 'node_modules' folder to source control.

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

#140

Post by paulhodge »

cluckindan wrote: post #96
bamboozled wrote: post #46

Can anyone tell me if yarn just as vulnerable as NPM? Isn't it the packages that are vulnerable and not the package manger software itself?

No, the ”vulnerability” here is npm unilaterally allowing postinstall scripts, which are then used as an entry point for malware. Of course, the malware could just embed itself as an IIFE and get launched when the package is loaded, so disallowing postinstall is not really a security solution.

Pnpm 10.x also has a feature to disallow post-install scripts by default. When using Pnpm you have to specifically enable a dependency to let it run its post-install scripts. It's a great feature that should be the standard.

Yes if someone compromises a package then they can also inject malicious code that will trigger at runtime.

But the thing about the recent NPM supply chain attack - it happened really quickly. There was a chain reaction of packages that got compromised which lead to more authors getting compromised. And I think a big reason why it moved so quickly was because of post-install scripts. If the attack happened more slowly, then the community would have more time to react and block the compromised packages. So just slowing down an attack is valuable on its own.

Post reply on HN