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.

▲

outloudvi 4 hours ago | parent [-]

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

▲

pixl97 4 hours ago | parent [-]

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

The nature of some of these attacks, it does. If your developers machine with publishing rights gets rooted a cool down makes credential gathering attacks via script in npm so very much harder it's not even funny.

In some of the recent supply chain attacks the entire fiasco was only a few hours long, but in that time tens of hundreds of thousands of credentials may have been stolen.

One day timers have the weakness of weekends and holidays reducing the number of eyes/systems seeing the issue.

	▲	outloudvi 4 hours ago \| parent [-]
		After reading the comments I now agree a short-length cooldown (maybe 1 or 3 days) is beneficial, given the following assumptions: - Independent security companies are scanning the packages (be careful if the project is depending on some no-so-popular packages) - Maintainers react promptly (it would be nonsense if people need to cooldown for 21 days because people may have 21-day vacations)