Live data from Hacker News

NPM's release cooldown is security theater

blog.outv.im

41–50 of 78 posts

Re: NPM's release cooldown is security theater

#41
A decent amount of recent issues follow the pattern where someone's credentials are compromised, those compromised credentials are used to release a malicious package, and then the original maintainer is the one to notice it but it takes them a little while to get the bad package pulled. A cooldown pretty much completely solves that problem.

Beyond that, a lot of these cooldown criticisms assume everyone will use the same length, which isn't how it has to work. There are people who run Arch because they want the latest version of everything, and there are people who run Debian because they never want a new version to break their system. Some people camp out for the newest iPhone on day 1, and some people wait to see reviews and find out if the antenna is sensitive to how the phone is held. Adjustable cooldowns let everyone choose their own balance between getting the latest features and getting something that is tested.

Re: NPM's release cooldown is security theater

#42
post #25
post #7

The archaic model where every tool gets full access to your home directory was never designed for the scenario where a single npm install will install and execute 100s of packages written by various authors. One should sandbox all npm command executions. https://github.com/ashishb/amazing-sandbox

Switch to another user, idealy called 'npm'. su -l npm Then, just in case, run it under bubblewrap so it just can use $HOME and nothing more.

[deleted]

Re: NPM's release cooldown is security theater

#43
post #31

Earlier quoted context omitted.

100% agree. I hated this post because it's all based on this unfounded assumption as an axiom, which it presents using zero evidence. Different groups have different risks tolerances, and it's absurd to think that nobody is going to pull releases before the default cool down period.

> it's absurd to think that nobody is going to pull releases before the default cool down period. Why is that absurd? It seems like a more likely outcome than just assuming there are enough "security researchers" out there doing this for every package?! IMO both sides here seem to have no evidence that the other is wrong.

Because I can always bump up the cooldown period. I'm not naive in thinking that I never have to worry about anything with a cooldown period, but having rolling releases is inherently what cooldowns give you. Companies have been doing rolling releases on their own products for years because it's a lot easier to handle when something falls over for a small percentage of users that when in nukes everyone all at once. That same concept still applies here.

Re: NPM's release cooldown is security theater

#44

> If everyone sets a cooldown, there will be no early adopter. Everyone is waiting for everyone else to be the canary, and the canary does not exist. Except there are researchers chomping at the bit to download every new release of packages in search of vulnerabilities they can exchange for fiat, reputational credit, or both.

That's better than nothing, but if you're expecting people to be looking at something before you use it, you should be waiting for a thumbs up from them, not waiting some arbitrary timespan for the absence of a thumbs down. You should probably also be paying them directly.

I don’t think it makes a ton of sense for individual OSS maintainers to pay companies for security. The point of cooldowns is that they’re free and they trend towards security at no logistical cost to maintainers.

(I agree that companies should pay for security products, of course. The bigger problem there is that so many security products are terrible, and supply chain products appear to be no different as a class.)

Re: NPM's release cooldown is security theater

#45

I wonder if the author has ever worked in IT. The idea of not moving quickly to new software versions has been around for decades. There are always early adopters and researchers looking at new, publicly available software. Critical industries have long waited for software releases to be stable and "recommended" by the vendor before upgrading, letting those early adopters who can afford some availability risk take ti…

> The idea of not moving quickly to new software versions has been around for decades.

There are COBOL users and CentOS 6 users. They aren't affected by this issue.

They might need to face another set of issues like vulnerability backporting and so on. People not worrying about cooldowns might still need to patch their log4j libraries, but that's another thing. This post is not for them.

> There are always early adopters and researchers looking at new, publicly available software.

I agree with that. These hacks are very unlikely to go unnoticed, especially for popular packages (although they do happen; `chalk` has 3M downloads per week when it was hacked).

> The observation that "if everyone in production has a cooldown, the benefit is gone" is an absolutist opinion.

Yes. However, I think this is eventually becoming some type of pointless arms race, as cooldown does not act actively towards reducing ecosystem attacks.

To add a somehow random example, pnpm's default cooldown time is 1 day. Yarn's 7 days. I'm not sure whether one day pnpm would also change it to 7 days because of people asking.

Re: NPM's release cooldown is security theater

#46

> If everyone sets a cooldown, there will be no early adopter. Everyone is waiting for everyone else to be the canary, and the canary does not exist. Except there are researchers chomping at the bit to download every new release of packages in search of vulnerabilities they can exchange for fiat, reputational credit, or both.

That's better than nothing, but if you're expecting people to be looking at something before you use it, you should be waiting for a thumbs up from them, not waiting some arbitrary timespan for the absence of a thumbs down. You should probably also be paying them directly.

It's a game of probabilities. Waiting longer means a higher probability that someone found something before you upgrade.

Most of the attacks we have seen lately are from legitimate projects which got compromised. The maintainers of those projects are generally looking out for that.

Re: NPM's release cooldown is security theater

#47
I think this is such an nefariously unnecessary negative argument.

Most, if not all, of the shai-hulud attacks that hit npm and other ecosystems were preventable with cooldowns. And these were not detected because regular users reported the worms, but because security researchers did. I don’t think I’ve ever seen an attack that was discovered because a user reported it.

Re: NPM's release cooldown is security theater

#48

> If everyone sets a cooldown, there will be no early adopter. This ignores all the security companies & researchers screening packages.

Isn't this what alpha/beta/RC releases are for, ensuring that there are no issues before a general release? I just don't get ecosystem has decided to use client-side configurations for this rather than just marking the releases in the ways that already exist.

Re: NPM's release cooldown is security theater

#49
post #31

Earlier quoted context omitted.

100% agree. I hated this post because it's all based on this unfounded assumption as an axiom, which it presents using zero evidence. Different groups have different risks tolerances, and it's absurd to think that nobody is going to pull releases before the default cool down period.

> it's absurd to think that nobody is going to pull releases before the default cool down period. Why is that absurd? It seems like a more likely outcome than just assuming there are enough "security researchers" out there doing this for every package?! IMO both sides here seem to have no evidence that the other is wrong.

Because security companies/researches are doing just that. The vast majority of recent supply chain attacks have only lasted minutes to hours. A large portion of them were credential losses or tag takeovers that aren't hard to detect, but by the time you do, your CI/CD has already downloaded and ran the attack 200 times.

Re: NPM's release cooldown is security theater

#50

> If everyone sets a cooldown, there will be no early adopter. Everyone is waiting for everyone else to be the canary, and the canary does not exist. Except there are researchers chomping at the bit to download every new release of packages in search of vulnerabilities they can exchange for fiat, reputational credit, or both.

The proliferation of these posts with such obviously terrible argumentation almost has me believing that they're a psy-op from some malicious actor (such as a US agency) which doesn't want people to improve their security. I mean why would you post drivel like this if you don't benefit from the status quo.

The most likely explanation is obviously that it's just a bunch of attention seeking amateur. But damn.

Post reply on HN