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

141–150 of 152 posts

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

#141

Post by davidshepherd7 »

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.

IIUC chainguard is this, but only for python, java, and docker images so far. https://www.chainguard.dev/libraries

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

#142

Post by motorest »

kjok wrote: post #105
hobofan wrote: post #100

Earlier quoted context omitted.

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

You're right that registries are under-resourced. But, if automated malware scanning actually worked, we'd already see big tech partnering with package registries to run continuous, ecosystem-wide scanning and detection pipelines. However, that isn't happening. Instead, we see piecemeal efforts from Google with assurance artifacts (SLSA provenance, SBOMs, verifiable builds), Microsoft sponsoring OSS maintainers, Face…

> But, if automated malware scanning actually worked, we'd already see big tech partnering with package registries to run continuous, ecosystem-wide scanning and detection pipelines.

I think this sort of thought process is misguided.

We do see continuous, ecosystem-wide scanning and detection pipelines. For example, GitHub does support DependaBot, which runs supply chain checks.

https://github.com/dependabot

What you don't see is magical rabbits being pulled out of top hats. The industry has decades of experience with anti-malware tools in contexts where said malware runs in spite of not being explicitly provided deployment or execution permissions. And yet it deploys and runs. What do you expect if you make code intentionally installable and deployable, and capable of sending HTTP requests to send and receive any kind of data?

Contrary to what you are implying, this is not a simple problem with straight-forward solutions. The security model has been highly reliant on the role of gatekeepers, both in producer and consumer sides. However, the last batch of popular supply chain attacks circumvented the only failsafe in place. Beyond this point, you just have a module that runs unspecified code, just like any other module.

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

#143

Post by kaelwd »

postepowanieadm wrote: post #2

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.

The chalk+debug+error-ex maintainer probably would have noticed a few hours later when they got home and saw a bunch of "Successfully published" emails from npm that they didn't trigger.

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

#144

Post by phatfish »

getcrunk wrote: post #138
davidpfarrell wrote: post #128

Earlier quoted context omitted.

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

Probably because they would expose themselves legally? Not sure what the current situation is exactly, but I assume it's "at your own risk".

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

#145

Post by Flimm »

mnahkies wrote: post #118
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 mome…

Thank you for the explanation. And thank you for your important work making the ecosystem more secure, for the benefit of 5.5 billion Internet users.

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

#147

Post by esafak »

chr15m wrote: post #137
esafak wrote: post #82

Earlier quoted context omitted.

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

It's not about managing churn; it's about making it easy to refactor by leaving open the option to use newer versions of libraries, or add dependencies that themselves depend on newer versions of libraries. And the way to do that is to continually pay off the tech debt in upgrading your dependencies.

Do you only write utilities that are fire and forget? Most people write applications whose specifications constantly evolve.

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

#148

Post by dwoldrich »

paulhodge wrote: post #139
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.

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

What benefit does doing that give me that the package-lock.json does not already provide?

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

#149

Post by paulhodge »

dwoldrich wrote: post #148
paulhodge wrote: post #139

Earlier quoted context omitted.

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

What benefit does doing that give me that the package-lock.json does not already provide?

it's kind of tongue-in-cheek but it would provide the maximum amount of isolation from any upstream package changes. Even if the package versions are removed from NPM (which happens in rare cases), you'd still have a copy.

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

#150

Post by ____tom____ »

IanCal wrote: post #34
keraf wrote: post #32

I might be naive but why isn't any package manager (npm, pnpm, bun, yarn, ...) pushing for a permission system, where packages have to define in the package.json what permission they would like to access? À la Deno but scoped to dependencies or like mobile apps do with their manifest. I know it would take time for packages to adopt this but it could be implemented as parameters when installing a new dependency, like…

I feel like that would require work from the language side, or at least runtimes. Is there a way of stopping code in one package from, say, hitting the network? You might be able to do this around install scripts, though disk writing is likely needed for all (but perhaps locations could be controlled).

Java had support for something very like this, but no one used it, and they recently removed it. https://openjdk.org/jeps/486

It's too bad, it would be useful in this situation

Post reply on HN