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

191–200 of 230 posts

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

#191

Post by Barbing »

latexr wrote: post #173
Barbing wrote: post #149

Earlier quoted context omitted.

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.

:)

I like it. Well, it would be tough for everybody whenever a long-awaited feature arrived but was out of touch just behind the glass. Maybe will improve our delayed gratification appreciation!

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

#192

Post by sidewndr46 »

cluckindan wrote: post #62
nirvdrum wrote: post #45

Earlier quoted context omitted.

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but i…

What important functionality do you feel is missing from the commonly used JS environments (node and browser) that is causing people to install it as a third party dependency? The issue isn’t that the functionality doesn’t exist, it’s always backwards compatibility with versions where it did not yet exist.

How can one have a backwards compatibility issue if the solution didn't exist yet?

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

#193

Post by bakkoting »

Hackbraten wrote: post #185
eranation wrote: post #161

Earlier quoted context omitted.

These get detected almost immediately, and removed by npm within hours (axios, tanstack at least)

But who will detect them on day one once everyone ignores them for seven days?

These things are usually caught by tools specifically scanning npm or by the maintainers noticing their account is compromised, not by people auditing their own installed packages.

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

#194

Post by kentm »

eranation wrote: post #118
themafia wrote: post #113

Earlier quoted context omitted.

Release escrow. Teams should be able to say "at least N developers have to agree to a release before it happens." This should be a policy they can control and lock down with a non developer account.

Interesting idea, but there are so many cases of solo maintainers. I think that npm can have its own cooldown and automated security scan. Socket.dev, StepSecurity both close a gap here by spending tokens to scan new popular packages. Whether they do it for marketing or out of the goodness of their heart, is irrelevant. They don’t charge for this service, and it’s something I’d expect Microsoft (who owns GitHub who o…

Heavy use of packages with solo maintainers is part of the problem here. Having multiple people looped in with proper governance doesn’t completely solve the issue but it makes it much harder to execute supply chain attacks.

It’s a bitter pill that we collectively don’t want to swallow, because it has a lot of negative connotations on our ability to deliver individual impact quickly.

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

#195

Post by jollyllama »

bichiliad wrote: post #85
jollyllama wrote: post #20

Earlier quoted context omitted.

> It seems like it might just be that Python/npm are juicier targets? Attackers go where the victims are. Frontend is a monoculture with the vast majority using NPM; backend, less so. This isn't an excuse for NPM, but another strike against it. You could also argue that the attacks make a deeper point about frontend vs backend devs, but I won't go there.

Why would you even imply something like that?

The fact that a package manager which keeps separate versions of each package for each dependency that it has became the accepted default that everyone in the frontend community uses as a foundation for their projects speaks to a lack of care or understanding within that community for technical matters.

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

#196

Post by erikerikson »

This reads like an onion article

> residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy

Does anyone believe that claim? There's been so many counterexamples.

It's a great dig on the ecosystem's failings but only entertainment. Perhaps a prompt for marketers to present their wares? Kinda like the maintainer of depsguard who removed, re-added, and then re-removed that admission from their post? At the time of this writing they have the top post.

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

#197

Post by forgotTheLast »

erikerikson wrote: post #196

This reads like an onion article > residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy Does anyone believe that claim? There's been so many counterexamples. It's a great dig on the ecosystem's failings but only entertainment. Perhaps a prompt for marketers to present their wares? Kinda like the maintainer of depsguard who rem…

Yes, it's derivative of the onion article on mass shootings: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

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

#198

Post by compel2160 »

jagged-chisel wrote: post #189
eranation wrote: post #64

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

I'm not so sure cooldown would be effective. Someone still has to override the cooldown to install the (potentially) questionable releases and discover problems. If no one does, you've only delayed the problems by 3/7/10/14 days. After thinking more while typing this: I think I'd agree we should indeed have a 10-day cooldown (i.e. don't install anything released in the last ten days.) I suppose I just don't think any…

I don't think anyone is saying cooldowns are the only thing you need - just that it's a 30sec change that should harden your code.

Also, most malicious versions seem to be detected by tools scanning new packages. People updating without cooldowns probably aren't manualy inspecting diffs. Giving tools more time to detect things seems pretty obviously good to me. Add to that maintainers reporting they've been pwned, and the floor for sneaking malicious code is much higher.

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

#199

Post by rascul »

marcosdumay wrote: post #99
lostglass wrote: post #26

Earlier quoted context omitted.

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.

Programs in Rust (or almost every other language) normally have fewer dependencies by 2 or 3 orders of magnitude. And that number tends to reduce even more when the ecosystem matures.

It may be fewer but it still doesn't feel good when cargo pulls in hundreds of deps for a seemingly simple application. But maybe it seems simple because of all the deps...

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

#200

Post by compel2160 »

Hackbraten wrote: post #186
reshlo wrote: post #166

Earlier quoted context omitted.

These compromises are usually caught within hours by security researchers performing automated scanning of all published packages.

Except that exhaustively scanning for badness is provably impossible. It's inevitable that a false negative will slip through one day, and when that happens, it will compromise everyone who installs it, no matter if on day one or day eight.

The idea isn't to comprehensively make malicious code impossible - the idea is to make it difficult to sneak in. If the NSA wants to spend 500 billion$ to compromise an NPM package, there's very little we can do. But if waiting 3 days for security scans catch even 10% of malicious packages, that 's 10% fewer incidents everyone else has to deal with. And now people pwning maintainers must be much more sophisticated so their attacks are entirely undetected for that period.
Post reply on HN