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

111–120 of 152 posts

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

#111

Post by anematode »

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…

The latest incident was detected first by an individual researcher (haven't verified this myself, but trusting you here) -- or maybe s/he was just the fastest reporter in the west. Even simple heuristics like the sudden addition of high-entropy code would have caught the most recent attacks, and obviously there are much better methods too.

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

#112

Post by chowells »

Rockslide wrote: post #99
mirashii wrote: post #90

Earlier quoted context omitted.

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

I mean, it's my #1 experience using npm. I never once have used `npm install` and had a result other than it changing the lockfile. Maybe you want to blame this on the tools I used, but I followed the exact installation instructions of the project I was working on. If it's that common to get it "wrong", it's the tool that is wrong.

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

#114

Post by Rockslide »

streptomycin wrote: post #108
Rockslide wrote: post #71

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.

My bad, it really annoyed me when npm stopped respecting lockfiles years ago so I stopped using it. That's great news that they eventually changed their mind. However in rare cases where I am forced to use it to contribute to some npm-using project, I have noticed that the lockfile often gets updated and I get a huge diff even though I didn't edit the dependencies. So I've always assumed that was the same issue with…

Well there are other lockfile updates as well, which aren't dependency version changes either. e.g. if the lockfile was created with an older npm version, running npm install with a newer npm version might upgrade it to a newer lockfile format and thus result in huge diffs. But that wouldn't change anything about the versions used for your dependencies.

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

#115

Post by ozim »

otterley wrote: post #104
ozim wrote: post #16

Earlier quoted context omitted.

NPM packages follow semantic versioning so minor versions should be fine to auto update. (there is still an issue what for package maintainer might be minor not being minor for you - but let's stick to ideal world for that) I don't think people are having major versions updated every month, it is more really like 6 months or once a year. I guess the problem might be people think auto updating minor versions in CI/CD…

> so minor versions should be fine to auto update The problem is that "should" assumes that point releases never introduce regressions (whether they be security, performance, or correctness). Unfortunately, history has shown that regressions can and do happen. The best practice for release engineering (CI/CD, if you will) is to assume the worst, test thoroughly, and release incrementally (include bake time). Delaying…

Regressions are irrelevant in this context, you can accept regressions as something you will deal with in case those happen or not.

Simply installing update automatically you get pwned by bad guys, someone taking over your CI/CD server or infrastructure is not something acceptable.

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

#116

Post by Flimm »

How is the age of a package calculated? If the publishing date of a package is obtained from the package's metadata defined by the package author, (just like Git commit dates are defined by the Git committer), then that would defeat the purpose of this new feature. The whole purpose of this feature is to protect from malicious or compromised package authors. Instead, it is necessary to query the package registry, trusting the package registry for the age of the package, rather than the package author. I presume this is how it works.

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

#118

Post by mnahkies »

Flimm wrote: post #116

How is the age of a package calculated? If the publishing date of a package is obtained from the package's metadata defined by the package author, (just like Git commit dates are defined by the Git committer), then that would defeat the purpose of this new feature. The whole purpose of this feature is to protect from malicious or compromised package authors. Instead, it is necessary to query the package registry, tru…

Eh we got confused implementing this today.

Basically we severed connection to the public npm registry completely earlier in the week whilst this worm plays out.

Unfortunately there wasn't a way to do this without taking our cached "good" public packages down as well, so we later replicated the good cached packages into a new standalone private registry to be the new upstream.

The bit that was not obvious in the moment but self evident once we realised is that the registry we're using took the copy time as the publish time, and therefore our new 2 week delay is rejecting the copied packages...

So sample size of one, but the registry we're using is definitely using upload time not any metadata in the packages themselves. Good to know the filtering is working.

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

#119

Post by otterley »

ozim wrote: post #115
otterley wrote: post #104

Earlier quoted context omitted.

> so minor versions should be fine to auto update The problem is that "should" assumes that point releases never introduce regressions (whether they be security, performance, or correctness). Unfortunately, history has shown that regressions can and do happen. The best practice for release engineering (CI/CD, if you will) is to assume the worst, test thoroughly, and release incrementally (include bake time). Delaying…

Regressions are irrelevant in this context, you can accept regressions as something you will deal with in case those happen or not. Simply installing update automatically you get pwned by bad guys, someone taking over your CI/CD server or infrastructure is not something acceptable.

That makes the advice all the more important, rather than making it "irrelevant." My point was that people mistakenly believe point releases are safe to apply automatically. They're not, and not just because of security.

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

#120

Post by Imustaskforhelp »

nikanj wrote: post #110
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.

Automated scans have detected 72251 out of the previous 3 supply-chain attacks

Reminds me of that michael burry quote.
Post reply on HN