Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should all be using dependency cooldowns

blog.yossarian.net

Post reply on HN
Print view View original

71–80 of 287 posts

Re: We should all be using dependency cooldowns

#71

Post by jcalvinowens »

woodruffw wrote: post #66
jcalvinowens wrote: post #63

Earlier quoted context omitted.

No you can't, the cooldown period is started by the new upstream release. So if you follow this "rule" you're guaranteed to be behind the latest upstream release.

I don't understand what you mean. The cooldown period is something you decide to enforce; you can always override it. It's your prerogative as a responsible engineer to decide the boundaries of policy enforcement.

I mean, you can do anything you want. But you're inventing a new definition of "cooldown" different than TFA...

Re: We should all be using dependency cooldowns

#72

Post by hypeatei »

mirashii wrote: post #61
hypeatei wrote: post #52

Earlier quoted context omitted.

> Sadly, not enough tooling seems to take this into account Most tooling (e.g. Dependabot) allows you to set an interval between version checks. What more could be done on that front exactly? Devs can already choose to check less frequently.

The check frequency isn't the problem, it's the latency between release and update. If a package was released 5 minutes before dependabot runs and you still update to it, your lower frequency hasn't really done anything.

What are the chances of that, though? The same could happen if you wait X amount of days for the version to "mature" as well. A security issue could be found five minutes after you update.

EDIT: Github supports this scenario too (as mentioned in the article):

https://github.blog/changelog/2025-07-01-dependabot-supports...

https://docs.github.com/en/code-security/dependabot/working-...

Re: We should all be using dependency cooldowns

#73

Post by woodruffw »

jcalvinowens wrote: post #71
woodruffw wrote: post #66

Earlier quoted context omitted.

I don't understand what you mean. The cooldown period is something you decide to enforce; you can always override it. It's your prerogative as a responsible engineer to decide the boundaries of policy enforcement.

I mean, you can do anything you want. But you're inventing a new definition of "cooldown" different than TFA...

I wrote TFA, so I can ensure you that this is what I meant :-)

(Can you say more about what you found unclear in the post? The post definitely does not say "thou shall not update before the cooldown," the argument was that cooldowns are a great default. Engineers are fundamentally always expected to exercise discretion because, per the post, there's no single, sound, perfect solution to supply chain risks.)

Re: We should all be using dependency cooldowns

#74

Post by jcalvinowens »

woodruffw wrote: post #73
jcalvinowens wrote: post #71

Earlier quoted context omitted.

I mean, you can do anything you want. But you're inventing a new definition of "cooldown" different than TFA...

I wrote TFA, so I can ensure you that this is what I meant :-) (Can you say more about what you found unclear in the post? The post definitely does not say "thou shall not update before the cooldown," the argument was that cooldowns are a great default. Engineers are fundamentally always expected to exercise discretion because, per the post, there's no single, sound, perfect solution to supply chain risks.)

> A “cooldown” is exactly what it sounds like: a window of time between when a dependency is published and when it’s considered suitable for use.

^ This is what you wrote. I don't understand how that could possibly be interpreted any other way than I wrote above: an enforced delay on deploying the new code after upstream releases it.

> The post definitely does not say "thou shall not update before the cooldown," the argument was that cooldowns are a great default

Sorry, that is such a cop out. "I didn't actually mean you should do this, I mean you should consider if you should maybe do this and you are free to decide not to and don't argue with me if you disagree every case is different". Either take a stand or don't.

Re: We should all be using dependency cooldowns

#75

Post by jerf »

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…

Also, if you are updating "right away" it is presumably because of some specific vulnerability (or set of them). But if you're in an "update right now" mode you have the most eyes on the source code in question at that point in time, and it's probably a relatively small patch for the targeted problem. Such a patch is the absolute worst time for an attacker to try to sneak anything in to a release, the exact and complete opposite of the conditions they are looking for.

Nobody is proposing a system that utterly and completely locks you out of all updates if they haven't aged enough. There is always going to be an override switch.

Re: We should all be using dependency cooldowns

#76

Post by Y_Y »

pengaru wrote: post #33
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.

How do you think dang puts bread on the table?

Re: We should all be using dependency cooldowns

#77

Post by tracnar »

embedding-shape wrote: post #46
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…

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

You could use this funky tool from oss-rebuild which proxies registries so they return the state they were at a past date: https://github.com/google/oss-rebuild/tree/main/cmd/timewarp

Re: We should all be using dependency cooldowns

#78

Post by pas »

embedding-shape wrote: post #46
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…

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

> "it'll only get harder in the future"

that's generally true, no?

of course waiting a few days/weeks should be the minimum unless there's a CVE (or equivalent) that's applies

Re: We should all be using dependency cooldowns

#79

Post by jerf »

embedding-shape wrote: post #46
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…

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

I fought off the local imposition of Dependabot by executive fiat about a year ago by pointing out that it maximizes vulnerabilities to supply chain attacks if blindly followed or used as a metric excessively stupidly. Maximizing vulnerabilities was not the goal, after all. You do not want to harass teams with the fact that DeeplyNestedDepen just went from 1.1.54-rc2 to 1.1.54-rc3 because the worst case is that they upgrade just to shut the bot up.

I think I wouldn't object to "Dependabot on a 2-week delay" as something that at least flags. However working in Go more than anything else it was often the case even so that dependency alerts were just an annoyance if they aren't tied to a security issue or something. Dynamic languages and static languages do not have the same risk profiles at all. The idea that some people have that all dependencies are super vital to update all the time and the casual expectation of a constant stream of vital security updates is not a general characteristic of programming, it is a specific characteristic not just of certain languages but arguably the community attached to those languages.

(What we really need is capabilities, even at a very gross level, so we can all notice that the supposed vector math library suddenly at version 1.43.2 wants to add network access, disk reading, command execution, and cryptography to the set of things it wants to do, which would raise all sorts of eyebrows immediately, even perhaps in an automated fashion. But that's a separate discussion.)

Post reply on HN