NPM's release cooldown is security theater

paulryanrogers

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

normie3000

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

some_random

I think the author is just totally ignorant, there's a whole community of security companies and researchers who are scanning every single package as it's released and have been doing so for some time now. Some of the details like how long the cooldown should be for are certainly up in the air, but the numbers have reasoning behind them.

filipn

I don't agree with this take, there are a bunch of security companies that are screening new versions of packages looking for vulnerabilities, so waiting a bit before upgrading to the lastest package is miles better than immediately upgrading.

ashishb

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

Surac

I do not use NPM. Works like a charm. Your mileage may vary

cpburns2009

I don't disagree with this take. But I'm not going to risk installing a package uploaded 1 hour ago considering all of the compromises this year. I think a cooldown period is prudent to let the automated security scanners to do their thing.

loloquwowndueo

Depending on those vaunted “security researchers” to take point and find all vulnerabilities in all packages is also fairly naive. That process costs money and produces a fairly valuable result - why would they give it away for free? So this will inevitably evolve into targeting only the high-value most popular packages and the exploiters will retreat to the long tail of less-popular ones. Lower payoff? Sure, but beats zero payoff.

colechristensen

>If everyone In no circumstances will everyone. This is just a bad take based on a silly premise.

akerl_

Even setting aside that there are, in fact, many human and robot eyes staring hard at the firehose of published packages on popular registries, the whole argument feels like a false dichotomy. If you're going to "DYOR" or whatever, having your automated dependency management on a cooldown timer seems like a snazzy way to smoothly provide a window for all your fancy dependency validation to happen.

unethical_ban

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 time with it. The observation that "if everyone in production has a cooldown, the benefit is gone" is an absolutist opinion. I have seen this occur in some fashion - my company's product has a software version that's been out for almost six months and we still tell customers in critical industries to stay on the older version out of an abundance of caution and with the understanding of what upgrades require for them. Stability > features.

Quothling

I am so uncultured that I was wondering why on earth we were waiting for Godot... But it's of couse because it's THAT Godot and not the game engine.

grahar64

I'm pretty sure it isn't. I actually proposed a cooldown for apt-get in my PhD thesis in 2013 and calculated its impact. Because the meta-data for the Ubuntu apt repository can be completely downloaded you can simulate the impact of a cooldown on how many less packages would be installed and it isn't zero. There are always people in a community running beta version, or up to date versions. There will be less with a cool down, but then depending on how critical your system is you could adjust cooldown length

hn_throwaway_99

How do posts like this make it to the top of HN? Nearly all the comments here are saying the same thing I thought: 1. Security researchers and companies are incentivized to install packages early. 2. Even without security patches, people and teams can still set the cooldown period that is appropriate to their risk tolerance. Even if someone in the wild does "get bit", it's better that a smaller number of people get bit than everyone getting bit at the same time. That's not "security theater", that's limiting the blast radius. I'd also add that adding in cooldown periods lowers the incentives for bad guys to try to compromise a package in the first place because there is a much greater chance all their work will be for naught. So I started reading this post with interest, thinking it would have some reason I hadn't thought of, but it just boils down to the faulty premise that "Godot is not coming". Bullshit, at the very least I now have agency over where I am in the download timeline. I just don't understand how such bad posts built on the flimsiest of assumptions make it to the top of HN.

woodruffw

The conventional meaning of “security theater” requires performance instead of effective action. But the author doesn’t reach that meaning: they claim that cooldowns don’t universalize , which then gets misconstrued into “security theater.” I don’t agree with either claim: I don’t think they’re security theater, and I do think they universalize, contingent on there being security parties that are incentivized to scan packages. The latter is a big assumption, but I think it’s a win for us either way: if supply chain companies are actually capable of defending us, then we win. But if it turns out they can’t serve as the cooldown vanguard, then we have great evidence that they shouldn’t be trusted at all.

kej

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.

stephantul

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.

davexunit

We're so close to a full circle moment. Next up is "npm stable", a curated set of packages (a "distribution", say) known to work well that are supported for a couple of years with security patches.

jackb4040

Unlike most commenters here, I actually agree with most of this criticism. But there is one simple thing the delay gets you, which is a window for the dev to go on Twitter and announce that they were hacked.

hennell

What a poor take. Cooldowns certainly don't solve everything but 'out of the box' even with no vetters they'll help catch unauthorised releases on active projects because it's more time to notice. Account takeovers, deployment exploits whatever the root cause, given a few days it's incredibly likely maintainers will notice they've released an unexpected update and fix/sound an alarm. A lot of existing cases like this people realise pretty fast, but the packages might still be live for a few hours as NPM catches up. Cooldown entirely removes that 'updated at the wrong time' issue, an no-one even needs to actually look at the code at all. For inactive or intentionally malicious maintainers, yes it relies on vetting. But it's hardly a mythical 'canary' - there are already a lot of companies scanning every popular npm package, auditing new ones, or just generally analysing threats. I can think of at least 4 such companies without even trying, I'm sure there's loads more. And they'll continue because it's not warm hearted so much as promoting/testing their security scanning services and tools so they can get the kudos from being the first to spot X etc. Which often does hit the front of HN or reddit, but they don't need the massive cyber loudspeaker to be effective. Flagging the issue to maintainers, reporting to NPM security - with a cooldown in place the package can be voided before anyone really gets the chance to install it. This is literally how a lot of things are spotted already, just with that 'updated at the wrong time' issue catching unlucky people out. Does it solve everything? No. Will it reduce the amount of problems that make it to end users? Obviously yes. And for all the author's 'no one will do this', 'waiting for Godot' cries - what do they recommend? Running your own audits, using LLMs, static analysis and testing it yourself. Basically being the veter they claim no-one will be! Unless they don't intend to sound the alarm themselves, they are literally the canary they're looking for. Cooldowns aren't magic, but they're not security theater either.