We should all be using dependency cooldowns • Hacker News Board

Re: We should all be using dependency cooldowns

#31

Post by swatcoder » Fri, Nov 21, 2025, 5:15 PM UTC

jcalvinowens wrote: post #5

I hate this. Delaying real bugfixes to achieve some nebulous poorly defined security benefit is just bad engineering.

The point is to apply a cooldown to your "dumb" and unaccountable automation, not to your own professional judgment as an engineer.

If there's a bugfix or security patch that applies to how your application uses the dependency, then you review the changes, manually update your version if you feel comfortable with those changes, and accept responsibility for the intervention if it turns out you made a mistake and rushed in some malicious code.

Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them, and so don't need to be rushed in. And most others are "fixes" for issues that were apparently not presenting an eminent test failure or support crisis for your users and don't warrant being rushed in.

There's not really a downside here, for any software that's actually being actively maintained by a responsible engineer.

Re: We should all be using dependency cooldowns

#32

Post by exasperaited » Fri, Nov 21, 2025, 5:15 PM UTC

perlgeek wrote: post #26

Some scattered thoughts on that: * If everybody does it, it won't work so well * I've seen cases where folks pinned their dependencies, and then used "npm install" instead of "npm ci", so the pinning was worthless. Guess they are the accidental, free beta testers for the rest of us. * In some ecosystems, distributions (such as Debian) does both additional QA, and also apply a cooldown. Now we try to retrofit some of…

> * If everybody does it, it won't work so well

Indeed, this is a complex problem to solve.

And the "it won't work so well" of this is probably a general chilling effect on trying to fix things because people won't roll them out fast enough anyway.

This may seem theoretical but for example in websites where there are suppliers and customers, there's quite a chilling effect on any mechanism that encourages people to wait until a supplier has positive feedback; there are fewer and fewer people with low enough stakes who are willing to be early adopters in that situation.

What this means is that new suppliers often drop out too quickly, abandon platforms, work around those measures in a way that reduces the value of trust, and worse still there's a risk of bad reviews because of the reviewer's Dunning-Kruger etc.

I think the mechanism is important for people who really must use it, but there will absolutely be side effects that are hard to qualify/correct.

Re: We should all be using dependency cooldowns

#33

Post by pengaru » Fri, Nov 21, 2025, 5:16 PM UTC

cosmic_cheese wrote: post #22

I think there’s a much stronger argument for policies that both limit the number and complexity of dependencies. Don’t add it unless it’s highly focused (no “everything libraries” that pull in entire universes of their own) and carries a high level of value. A project’s entire dependency tree should be small and clean. Libraries themselves should perhaps also take a page from the book of Linux distributions and offer…

I'd be willing to pay $100 to upvote your comment 100x.

Re: We should all be using dependency cooldowns

#34

Post by cxr » Fri, Nov 21, 2025, 5:17 PM UTC

What everyone should all be doing is practicing the decades-old discipline of source control. Attacks of the form described in the post, where a known-good, uncompromised dependency is compromised at the "supply chain" level, can be 100% mitigated—not fractionally or probabilistically—by cutting out the vulnerable supply chain. The fact that people are still dragging their feet on this and resist basic source control is the only reason why this class of attack is even possible. That vendoring has so many other benefits and solves other problems is even more reason to do so.

Stacking up more sub-par tooling is not going to solve anything.

Fortunately this is a problem that doesn't even have to exist, and isn't one that anyone falls into naturally. It's a problem that you have to actively opt into by taking steps like adding things to .gitignore to exclude them from source control, downloading and using third-party tools in a way that introduces this and other problems, et cetera—which means you can avoid all of it by simply not taking those extra steps.

(Fun fact: on a touch-based QWERTY keyboard, the gesture to input "vendoring" by swiping overlaps with the gesture for "benefitting".)

Re: We should all be using dependency cooldowns

#35

Post by jcalvinowens » Fri, Nov 21, 2025, 5:19 PM UTC

bityard wrote: post #19

jcalvinowens wrote: post #8

Earlier quoted context omitted.

Yep. Not only vulnerabilities, but just bugs in general, which usually matter more than than vulnerabilities IMHO.

Do you believe new releases don't introduce new bugs?

Obviously. Every release introduces bugs. There's an inevitable positive correlation between the amount of code we write and the number of bugs we introduce, we just try to minimize it.

The probability of introducing bugs is a function of the amount of development being done. Releasing less often doesn't change that. In fact, under that assumption, delaying releases strictly increases the amount of time users are affected by the average bug.

People who do this tell themselves the extra time allows them to catch more bugs. But in my experience that's a bedtime story, most bugs aren't noticed until after deployment anyway.

That's completely orthogonal to slowly rolling out changes, btw.

Re: We should all be using dependency cooldowns

#36

Post by silvestrov » Fri, Nov 21, 2025, 5:19 PM UTC

layer8 wrote: post #20

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lot of software doesn't have continuous deployment, but instead has customer-side deployment of new releases, which follow a slower rhythm of several weeks or months, barring emergencies. They are fine. Most vulnerabilities that aren't supply-chain attacks are o…

I think the main question is: do your app get unknown input (i.e. controlled by other people).

Browsers get a lot of unknown input, so they have to update often.

A Weather app is likely to only get input from one specific site (controlled by the app developers), so it should be relatively safe.

Re: We should all be using dependency cooldowns

#37

Post by callamdelaney » Fri, Nov 21, 2025, 5:19 PM UTC

Anything to save us from not being able to apply because of a CVE which is only relevant if you're doing something which we don't.

Re: We should all be using dependency cooldowns

#38

Post by layer8 » Fri, Nov 21, 2025, 5:19 PM UTC

perlgeek wrote: post #26

Some scattered thoughts on that: * If everybody does it, it won't work so well * I've seen cases where folks pinned their dependencies, and then used "npm install" instead of "npm ci", so the pinning was worthless. Guess they are the accidental, free beta testers for the rest of us. * In some ecosystems, distributions (such as Debian) does both additional QA, and also apply a cooldown. Now we try to retrofit some of…

"If everybody does it, " is rarely a good argument, because the premise rarely becomes reality.

Re: We should all be using dependency cooldowns

#39

Post by starburst » Fri, Nov 21, 2025, 5:20 PM UTC

jcalvinowens wrote: post #13

wrs wrote: post #6

Earlier quoted context omitted.

Do you upgrade all your dependencies every day ? If not, then there’s no real difference in upgrading as if it were 7 days ago.

I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs…

Upgrading to new version can also introduce new exploits, no amount of tests can find those.

Some of these can be short-lived, existing only on a minor patch and fixed on the next one promptly but you’ll get it if you upgrade constantly on the latest blindly.

There is always risks either way but latest version doesn’t mean the “best” version, mistakes, errors happens, performance degradation, etc.

Re: We should all be using dependency cooldowns

#40

Post by K0nserv » Fri, Nov 21, 2025, 5:21 PM UTC

perlgeek wrote: post #26

Some scattered thoughts on that: * If everybody does it, it won't work so well * I've seen cases where folks pinned their dependencies, and then used "npm install" instead of "npm ci", so the pinning was worthless. Guess they are the accidental, free beta testers for the rest of us. * In some ecosystems, distributions (such as Debian) does both additional QA, and also apply a cooldown. Now we try to retrofit some of…

This is not how `npm install` works. This misunderstanding is so pervasive. Unless you change stuff in `package.json` `npm install` will not update anything, it still installs based on package-lock.json.

Quoting from the docs:

> This command installs a package and any packages that it depends on. If the package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the installation of dependencies will be driven by that [..]