> 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.
paulryanrogers
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.
filipn
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.
kej
> If everyone sets a cooldown, there will be no early adopter.
This ignores all the security companies & researchers screening packages.
normie3000
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.
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.
cpburns2009
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.
hn_throwaway_99
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.
loloquwowndueo
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.
akerl_
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.
comments (10)
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.
paulryanrogers
filipn
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.
kej
This ignores all the security companies & researchers screening packages.
normie3000
One should sandbox all npm command executions.
https://github.com/ashishb/amazing-sandbox
ashishb
cpburns2009
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.
hn_throwaway_99
loloquwowndueo
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.
akerl_
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.
woodruffw