Live data from Hacker News

Pnpm has a new setting to stave off supply chain attacks

pnpm.io

91–100 of 152 posts

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

#91
post #51

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.

I think there's some confusion here. No automated scan was able to catch the attack. It was an individual who notified these startups.

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

#93

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.

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 across all major package registries. The reality is, these systems still miss what vigilant humans catch.

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

#94
I feel like the correct solution to these problems (across NPM and all similar package managers) is a web-of-trust audit system based on:

- Reviewing the source code in the actual published package

- Tooling that enable one to easily see a trusted diff between a package version and the previous version of that package

- Built-in support in the package manager CLIs to only install packages that have a sufficient number of manual reviews from trusted sources (+ no / not too many negative reviews). With manual review required to bypass these checks.

There are enough users of each package that such a system should not be too onerous on users once the infrastructure was in place.

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

#95
post #43
post #7

Earlier quoted context omitted.

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

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.

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

#96

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.

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

#97
post #5

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.

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

TIL ISO8601 also standardizes duration

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

#98

Earlier quoted context omitted.

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.

Are you 100% on that?

Yes. As someone who's using npm install daily, and given the update cadence of npm packages, I would end up with dirty lock files very frequently if the parent statement were true. It just doesn't happen.

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

#99

Earlier quoted context omitted.

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.

> How does this get repeated over and over, when it's simply not true? Well, for one, the behavior is somewhat insane. `npm install` with no additional arguments does update the lockfile if your package.json and your lockfile are out of sync with one another for any reason, and so to get a guarantee that it doesn't change your lockfile, you must do additional configuration or guarantee by some external mechanism that…

> You've partially answered your own question here.

Is that the case? If it were ever true (outside of outright bugs in npm), it must have been many many years and major npm releases ago. So that doesn't justify brigading outdated information.

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

#100
post #93

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…

> If automated scanning were truly effective, we'd see deployments across all major package registries.

No we wouldn't. Most package registries are run by either bigcorps at a loss or by community maintainers (with bigcorps again sponsoring the infrastructure).

And many of them barely go beyond the "CRUD" of package publishing due to lack of resources. The economic incentives of building up supply chain security tools into the package registries themselves are just not there.

Post reply on HN