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

61–70 of 287 posts

Re: We should all be using dependency cooldowns

#61

Post by mirashii »

hypeatei wrote: post #52
embedding-shape wrote: post #46

Earlier quoted context omitted.

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

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

Re: We should all be using dependency cooldowns

#62

Post by woodruffw »

jcalvinowens wrote: post #8
jayd16 wrote: post #3

Doesn't this mean you're leaving yourself open to known vulnerabilities during that "cool down" time?

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

To be clear, there's no reason why you can't update dependencies in advance of a cooldown period. The cooldown is an enforced policy that you can choose to override as needed.

(This also doesn't apply to vulnerabilities per se, since known vulnerabilities typically aren't evaluated against cooldowns by tools like Dependabot.)

Re: We should all be using dependency cooldowns

#63

Post by jcalvinowens »

woodruffw wrote: post #62
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.

To be clear, there's no reason why you can't update dependencies in advance of a cooldown period. The cooldown is an enforced policy that you can choose to override as needed. (This also doesn't apply to vulnerabilities per se, since known vulnerabilities typically aren't evaluated against cooldowns by tools like Dependabot.)

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.

Re: We should all be using dependency cooldowns

#64

Post by programmertote »

I know it's impossible in some software stack and ecosystem. But I live mostly in the data world, so I usually could get away from such issues by aggressively keeping my upstream dependency list lean.

P.S. When I was working at Amazon, I remember that a good number of on-call tickets were about fixing dependencies (in most of them are about updating the outdated Scala Spark framework--I believe it was 2.1.x or older) and patching/updating OS'es in our clusters. What the team should have done (I mentioned this to my manager) is to create clusters dynamically (do not allow long-live clusters even if the end users prefer it that way), and upgrading the Spark library. Of course, we had a bunch of other annual and quarterly OKRs (and KPIs) to meet, so updating Spark got the lowest of priorities...

Re: We should all be using dependency cooldowns

#65

Post by robszumski »

l9o wrote: post #25

I wonder if LLMs can help here to some extent. I agree with others that cooldowns aren't helpful if everyone is doing it. I've been working on automatic updates for some of my [very overengineered] homelab infra and one thing that I've found particularly helpful is to generate PRs with reasonable summaries of the updates with an LLM. it basically works by having a script that spews out diffs of any locks that were up…

We built and launched this product about 2 months ago, HN thread here: https://news.ycombinator.com/item?id=45439721

Totally agree that AI is great for this, it will work harder and go deeper and never gets tired of reading code or release notes or migration guides. What you want instead of summaries is to find the breaking changes, figure out if they matter, then comment on _that_.

Re: We should all be using dependency cooldowns

#66

Post by woodruffw »

jcalvinowens wrote: post #63
woodruffw wrote: post #62

Earlier quoted context omitted.

To be clear, there's no reason why you can't update dependencies in advance of a cooldown period. The cooldown is an enforced policy that you can choose to override as needed. (This also doesn't apply to vulnerabilities per se, since known vulnerabilities typically aren't evaluated against cooldowns by tools like Dependabot.)

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.

Re: We should all be using dependency cooldowns

#67

Post by jayd16 »

swatcoder wrote: post #14
jayd16 wrote: post #3

Doesn't this mean you're leaving yourself open to known vulnerabilities during that "cool down" time?

No. A sane "cooldown" is just for automated version updates relying on semantic versioning rules, which is a pretty questionable practice in the first place, but is indeed made a lot more safe this way. You can still manually update your dependency versions when you learn that your code is exposed to some vulnerability that's purportedly been fixed. It's no different than manually updating your dependency version whe…

If you could understand the quality of updates you're pulling in, that solves the issue entirely. The point is that you can't.

There's no reason to pretend we live in a world where everyone is manually combing through the source of every dependency update.

Re: We should all be using dependency cooldowns

#68

Post by jcalvinowens »

swatcoder wrote: post #57
jcalvinowens wrote: post #50

Earlier quoted context omitted.

You're not thinking about the system dependencies. > 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 Sorry, this is really ignorant. You don't appreciate how much churn their is in things like the kernel and glibc, even in stable branches.

> You're not thinking about the system dependencies. You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed. If there's a zero day vulnerability that affects your system, which is a rare but real thing, you can be notified and bypass a cooldown system. Otherwise, you've pres…

> You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed.

Well, I've made a whole career out of fixing bugs like that. Just because you don't see them doesn't mean they don't exist.

It is shockingly common to see systems bugs that don't trigger for a long time by luck, and then suddenly trigger out of the blue everywhere at once. Typically it's caused by innocuous changes in unrelated code, which is what makes it so nefarious.

The most recent example I can think of was an uninitialized variable in some kernel code: hundreds of devices ran that code reliably for a year, but an innocuous change in the userland application made the device crash on startup almost 100% of the time.

The fix had been in stable for months, they just hadn't bothered to upgrade. If they had upgraded, they'd have never known the bug existed :)

I can tell dozens of stories like that, which is why I feel so strongly about this.

Re: We should all be using dependency cooldowns

#69

Post by smaudet »

jcalvinowens wrote: post #60
smaudet wrote: post #21

Earlier quoted context omitted.

> zero day is going to bite you in the ass Maybe your codebase is truly filled with code that is that riddled with flaws, but: 1) If so, updating will not save you from zero days, only from whatever bugs the developers have found. 2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them. 3) In the case where a real issue is found, I can't imagine…

My codebase runs on top of the same millions of lines of decades old system code that yours does. You don't seem to appreciate that :)

If you mean operating system code, that is generally opaque, and not quite what the article is talking about (you don't use a dependency manager to install code that you have reviewed to perform operating system updates - you can, and that is fantastic for you, but not I imagine what you mean).

Although, even for Operating Systems, cooldown periods on patches are not only a good thing, but something that e.g. a large org that can't afford downtime will employ (managing windows or linux software patches, e.g.). The reasoning is the same - updates have just as much chance to introduce bugs as fix them, and although you hope your OS vendor does adequate testing, especially in the case where you cannot audit their code, you have to wait so that either some 3rd party security vendor can assess system safety, or you are able to perform adequate testing yourself.

Re: We should all be using dependency cooldowns

#70

Post by jayd16 »

astrobe_ wrote: post #59
jayd16 wrote: post #3

Doesn't this mean you're leaving yourself open to known vulnerabilities during that "cool down" time?

TFA shows that most vulnerabilities have a "window of opportunity" smaller than one day. Are you anxious going on week-end because Friday evening a zero-day or a major bug could be made public?

Well then you agree that the answer is yes. At the end of the article a 14 day window is mentioned but not dismissed and does not mention the downsides.
Post reply on HN