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.
Pnpm has a new setting to stave off supply chain attacks
91–100 of 152 posts
Re: Pnpm has a new setting to stave off supply chain attacks
#92Re: Pnpm has a new setting to stave off supply chain attacks
#93If 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.
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- 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
#95Earlier 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
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
#96Can 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?
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
#97Re: Pnpm has a new setting to stave off supply chain attacks
#98Earlier 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?
Re: Pnpm has a new setting to stave off supply chain attacks
#99Earlier 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…
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
#100Earlier 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…
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.