If everyone impl. cooldown feature then it will be basically the same as now but delayed by cooldown period. Software/package user cannon fodders are needed for frontier live testing.
A developer is compromised and a malicious package is published. Even if the developer is immediately aware of the situation, it's a race to contact the package manager authority and get it taken down before anyone uses it.
There are researchers and other professionals that monitor package repos and try to detect this sort of thing. Giving them some lead time would definitely help.
The posts (FD: my posts) linked in TFA address this argument. The TL;DR is that there are scanning parties that are participants in open source ecosystems, and these parties are responsible for discovering malicious activity so that nobody needs to be cannon fodder.
I almost wonder if there is a case where this actually benefits malicious actors: suppose I can scan newly released packages and collect exploits while barely anyone else has eyes on them. Then I have a more comfortable time period to develop more effective payloads, and wait to deploy them until whatever the standard cooldown period is up (and there will be a standard cooldown period everyone will copypasta from some big tech co).
This is in contrast to now where malware authors are often incentivized to deploy as quickly as possible before others catch on.
I think that's an interesting point, but we're looking at two different threats. The one that's being addressed with cooldown is compromised releases, where the release itself is an attack on the userbase.
And the one you're pointing out (not incorrectly) is flawed releases, where a release introduces a new bug that could be used to attack the users.
There's some competition between these two concerns, to be clear. I'd say that for the FOSS I tend to be most interested in, though, I don't see how much advantage cooldown offers to the actors here. These packages are largely developed in the open. If I wanted to attack one, I wouldn't wait until the release ships. I'd be monitoring all new commits. And if I wanted to attack a non-FOSS release, I'd be subscribed to the insiders channel, getting pre-releases.
I could imagine some packages where the cooldown would give me meaningful extra time to find and build a reliable exploit, but public SCM and pre-release downloads already feel like they do 90+% of that job. That's an interesting angle wrt cooldown periods, though, and one I hadn't previously thought much about.
And actually, I thought about this more after I posted my original comment. It's almost like this introduces a race between the white and back hats, in which the minimum time to exploit (in the case the black hat wins) is the cooldown. Which is basically what is already happening, except without the minimum time. So this seems strictly better than the current situation.
I do think it would work better if people kept their cooldown periods to themselves though, as that's just less information for an attacker. I do fear that what would likely happen is some tool like dependebot introduces a default that people then never change, though.
I think the author is recommending an default setting that can be overridden. Organizations that need to be on the bleeding edge can override the default and get packages immediately. Regular consumers would wait one week.
Ecosystem security isn't zero-sum and so I don't expect beggar thy neighbor policies to last.
The counter-argument is that: (1) security vendors and package indexes are incentivized to find malicious packages and (2) not everyone will use cool downs. To be brief:
We already tried this model with anti-virus. It didn't work.
Security vendors get paid to sell vulnerabilities and XKCD-2347 dependencies don't have money to pay.
If cooldowns are the default, then mostly unsophisticated people will choose to live on the edge. (See also: Ubuntu PPAs, users of Debian unstable and Fedora rawhide)
If cooldowns aren't the default, then only unsophisticated people will "choose" to live on the edge.
I predict a move to phased updates / releases as is standard in the world of app stores and vendor updates. That is, maintainers will continue to release their packages as normal. But with each release, consumers will be randomly assigned to cohorts, with smaller cohorts updating earlier and larger cohorts updating later. That way the ecosystem as a whole fairly bears the burden.
Seems like a simple, elegant solution to a complex problem. I haven't really looked, but I imagine you can broadly override the cooldown in times of crisis? Let's say a package goes live after cooldown that breaks stuff downstream somehow, shipping the patch behind a cooldown would be problematic from the gems.coop level... but seems like a lot saner default than the current hellscape.
TotallyAsymetricSymbol | a day ago
If everyone impl. cooldown feature then it will be basically the same as now but delayed by cooldown period. Software/package user cannon fodders are needed for frontier live testing.
Relax | a day ago
There are still cases where it helps:
yossarian | a day ago
The posts (FD: my posts) linked in TFA address this argument. The TL;DR is that there are scanning parties that are participants in open source ecosystems, and these parties are responsible for discovering malicious activity so that nobody needs to be cannon fodder.
Fingel | 22 hours ago
I almost wonder if there is a case where this actually benefits malicious actors: suppose I can scan newly released packages and collect exploits while barely anyone else has eyes on them. Then I have a more comfortable time period to develop more effective payloads, and wait to deploy them until whatever the standard cooldown period is up (and there will be a standard cooldown period everyone will copypasta from some big tech co).
This is in contrast to now where malware authors are often incentivized to deploy as quickly as possible before others catch on.
hoistbypetard | 20 hours ago
I think that's an interesting point, but we're looking at two different threats. The one that's being addressed with cooldown is compromised releases, where the release itself is an attack on the userbase.
And the one you're pointing out (not incorrectly) is flawed releases, where a release introduces a new bug that could be used to attack the users.
There's some competition between these two concerns, to be clear. I'd say that for the FOSS I tend to be most interested in, though, I don't see how much advantage cooldown offers to the actors here. These packages are largely developed in the open. If I wanted to attack one, I wouldn't wait until the release ships. I'd be monitoring all new commits. And if I wanted to attack a non-FOSS release, I'd be subscribed to the insiders channel, getting pre-releases.
I could imagine some packages where the cooldown would give me meaningful extra time to find and build a reliable exploit, but public SCM and pre-release downloads already feel like they do 90+% of that job. That's an interesting angle wrt cooldown periods, though, and one I hadn't previously thought much about.
Fingel | 19 hours ago
Right, I was only thinking about flawed releases.
And actually, I thought about this more after I posted my original comment. It's almost like this introduces a race between the white and back hats, in which the minimum time to exploit (in the case the black hat wins) is the cooldown. Which is basically what is already happening, except without the minimum time. So this seems strictly better than the current situation.
I do think it would work better if people kept their cooldown periods to themselves though, as that's just less information for an attacker. I do fear that what would likely happen is some tool like dependebot introduces a default that people then never change, though.
chilton | a day ago
I think the author is recommending an default setting that can be overridden. Organizations that need to be on the bleeding edge can override the default and get packages immediately. Regular consumers would wait one week.
soulcutter | 18 hours ago
I still wish this was more-aptly called a quarantine.
quad | 12 hours ago
Ecosystem security isn't zero-sum and so I don't expect beggar thy neighbor policies to last.
The counter-argument is that: (1) security vendors and package indexes are incentivized to find malicious packages and (2) not everyone will use cool downs. To be brief:
I predict a move to phased updates / releases as is standard in the world of app stores and vendor updates. That is, maintainers will continue to release their packages as normal. But with each release, consumers will be randomly assigned to cohorts, with smaller cohorts updating earlier and larger cohorts updating later. That way the ecosystem as a whole fairly bears the burden.
ondreian | a day ago
Seems like a simple, elegant solution to a complex problem. I haven't really looked, but I imagine you can broadly override the cooldown in times of crisis? Let's say a package goes live after cooldown that breaks stuff downstream somehow, shipping the patch behind a cooldown would be problematic from the gems.coop level... but seems like a lot saner default than the current hellscape.