Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

'No way to prevent this,' says only package manager where this regularly happens

kevinpatel.xyz

Post reply on HN
Print view View original

171–180 of 230 posts

Re: 'No way to prevent this,' says only package manager where this regularly happens

#171

Post by darkteflon »

otabdeveloper4 wrote: post #134
saghm wrote: post #66

Earlier quoted context omitted.

I'm not convinced that Python should be the standard for package management either. Earlier this week I was trying to publish a Python package for the first time wrapping a Rust library I wrote (for use only on Linux and Python 3.12+), and it literally took me hours to get from "I have a wheel that I can import and it works on my system" to "I have published that wheel and can install the package from PyPI on the set…

> Python should be the standard for package management Python is the antistandard for package management. Or maybe even the eldritch horror of package management.

Thanks to uv, all is forgiven.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#172

Post by cindyllm »

dns_snek wrote: post #153
throwaway27448 wrote: post #145

Earlier quoted context omitted.

Trivial relative to which perspective? The distinction matters enough to care. Just because your father might give away their phone pin over the phone doesn't mean we should allow this granting remote access to his phone.

Trivial in the sense that in 99.9% of situations, "npm install" is immediately followed by "npm run", "npm test", or some form of execution. Any execution that imports a dependency is enough for a transitive dependency to execute its malicious payload immediately. Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time, but removi…

[dead]

Re: 'No way to prevent this,' says only package manager where this regularly happens

#173

Post by latexr »

Barbing wrote: post #149
chowells wrote: post #146

Earlier quoted context omitted.

A large portion of the time, the maintainer notices what happened a few hours later. Maybe they were asleep or off doing other things for a while, but they eventually come back. And these kinds of takeovers frequently aren't complete enough to cover their tracks. So at the very least, adding a cooldown raises the difficulty of these attacks above that threshold.

Would be bad for software/progress I guess but, got me thinking of if we had an expectation a dev would post an update checksum/hash, then follow it up a day later with the update itself... (well maybe that leads to kidnappings idk) edit - heh, sibling comment on package manager-level must be much smarter

> Would be bad for software/progress I guess but

We all need to slow down and get some perspective. “Progress” doesn’t mean “rush everything and do it now now now”. Advancements should be slow, methodical, considered. That’s a good thing, not a weakness.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#174

Post by seba_dos1 »

0xbadcafebee wrote: post #167
kelnos wrote: post #119

Earlier quoted context omitted.

No it's not. That's a terrible analogy.

It's exactly the same. With both you have no idea if you'll be compromised once you pick up a new item from the store. With both you wait a week, in case the authorities issue a recall. With both you use it after that one week of waiting. Both are relying on luck to be safe. The crazy thing is the risk from food is higher, we just don't really mind, because it's rare that we personally get affected

As much as I dislike this distribution model, this is a completely misapplied analogy. In npm with cooldowns case you "buy" a thing and get to use it instantly without any delay, it just won't get improved until a few days later - exactly as if the project you installed would use some timed staging channel for testing before making releases, except you're the one who controls the timing here.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#175

Post by nayroclade »

brunoborges wrote: post #80
cluckindan wrote: post #59

Earlier quoted context omitted.

How does that protect against credential theft? MFA required to sign published releases?

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

Dependency versions are also locked for npm projects via package-lock.json, and this has been the default behaviour for years. The version ranges specified in package.json don't mean you just pick up the latest whenever you run npm install. Unless you delete package-lock.json or run "npm update", you and everyone else gets the exact same dependency tree each time. So it is just as reproducible as a Maven build in that sense.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#177

Post by aselimov3 »

lostglass wrote: post #26
aselimov3 wrote: post #8

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

To be honest Rust has the exact same supply chain attack pattern - it's just newer and more maintained at the moment. Give it a decade.

Yea I’m a big fan of rust but it does feel uncomfortable to see my dependency blowing up to the hundreds when I build

Re: 'No way to prevent this,' says only package manager where this regularly happens

#178

Post by no-name-here »

yegle wrote: post #27

Vendorizing using git submodule should be a robust mitigation for this problem.

Wouldn't locking dependencies be far more likely for dependency-users to do, and be approximately as effective for those that do?

Re: 'No way to prevent this,' says only package manager where this regularly happens

#179

Post by Macha »

otabdeveloper4 wrote: post #134
saghm wrote: post #66

Earlier quoted context omitted.

I'm not convinced that Python should be the standard for package management either. Earlier this week I was trying to publish a Python package for the first time wrapping a Rust library I wrote (for use only on Linux and Python 3.12+), and it literally took me hours to get from "I have a wheel that I can import and it works on my system" to "I have published that wheel and can install the package from PyPI on the set…

> Python should be the standard for package management Python is the antistandard for package management. Or maybe even the eldritch horror of package management.

Part of me wonders if the reason we see more npm attacks than pypi attacks is malware authors not wanting to deal with python packaging either

Re: 'No way to prevent this,' says only package manager where this regularly happens

#180

Post by Macha »

10000truths wrote: post #122
joeblubaugh wrote: post #51

There has been a lot of pain at my various jobs installing a safe global npm config on every developer machine, asking people not to disable it, checking it with mdm tools. A safer out-of-the-box configuration is long overdue.

What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.

Whether the config is the registry URL or the cooldown timer you still need it on your dev machines and people to use tools that use it (the latter is especially a problem with docker in my experience, people find out testcontainers or whatever is pulling from docker hub rather than the company registry only when their CI build fails from rate limits)
Post reply on HN