Live data from Hacker News

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

kevinpatel.xyz

141–150 of 230 posts

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

#141
post #86
post #82

Earlier quoted context omitted.

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example). Who the heck says everyone who publishes a library has a domain? That seems absurd.

And domains can change hands legitimately.

Or be forgotten to renewed, lost and, depending on registrar, overtaken.

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

#142
post #90

Earlier quoted context omitted.

With respect, post-install scripts are a total red herring. You're alarmed by them because they are code controlled by someone else that runs on your box, and they could do something bad -- yes, they are, and yes they could. But so is the regular code in those packages! It won't run at install time, but something in there will run -- otherwise it wouldn't have been included in the dependencies. Thinking that eliminat…

The time difference does matter though. There were some recent worm attacks in NPM that spread very quickly because they used post-install. I don’t remember how long it took NPM to block the packages but it was probably around 30 minutes or so? If it wasn’t for post-install then that same attack would have a much slower spread and thus a smaller blast radius.

I don't accept the idea that it would significantly slow down the spread.

How often do you run "npm install" just for the fun of it, without actively working on the codebase?

IME 99% of the time the time between "npm install" and some form of execution that pulls in dependencies is less than 30 seconds.

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

#143

Do not fucking use npm. Stay the fuck away from it. Want to write JS? AI can now write vanilla JS for you with no libraries. Own your code.

I don't like vanilla JS though. I like easier-to-read abstracted JS.

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

#144

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…

Doesn’t that just move the problem 7 days down the road? I always assumed these kinds of things just burn themselves because someone gets infected and realizes, not that there is an army of people auditing the changes. If everyone cooldowns for 7 days, it just happens later?

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

#145

Earlier quoted context omitted.

Surely every layer of defense in depth is a distraction except the one that prevents the problem.

It's not defense in depth if the mechanism is trivially bypassed.

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.

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

#146

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…

Doesn’t that just move the problem 7 days down the road? I always assumed these kinds of things just burn themselves because someone gets infected and realizes, not that there is an army of people auditing the changes. If everyone cooldowns for 7 days, it just happens later?

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.

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

#147

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…

> Why cooldowns? Most npm (or pypi) compromises were taken down within hours,

But won't more people on cooldown mean less likelihood to catch the bug, thus extending the need for cooldowns?

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

#148

Earlier quoted context omitted.

Doesn’t that just move the problem 7 days down the road? I always assumed these kinds of things just burn themselves because someone gets infected and realizes, not that there is an army of people auditing the changes. If everyone cooldowns for 7 days, it just happens later?

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.

> large portion of the time, the maintainer notices what happened a few hours later.

So add it at the package manager level instead of the user level then?

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

#149

Earlier quoted context omitted.

Doesn’t that just move the problem 7 days down the road? I always assumed these kinds of things just burn themselves because someone gets infected and realizes, not that there is an army of people auditing the changes. If everyone cooldowns for 7 days, it just happens later?

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

Post reply on HN