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

swatcoder 10 hours ago | parent | next [-]

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 when you learn that there's some implementation bug or performance cliff that was fixed.

You might even still use an automated system to identify these kinds of "critical" updates and bring them to your attention, so that you can review them and can appropriately assume accountability for the choice to incorporate them early, bypassing the cooldown, if you believe that's the right thing to do.

Putting in that effort, having the expertise to do so, and assuming that accountability is kind of your "job" as a developer or maintainer. You can't just automate and delegate everything if you want people to be able to trust what you share with them.

	▲	jayd16 9 hours ago \| parent [-]
		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.

▲

astrobe_ 9 hours ago | parent | prev | next [-]

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?

	▲	jayd16 9 hours ago \| parent [-]
		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.

▲

jcalvinowens 10 hours ago | parent | prev [-]

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

▲

bityard 10 hours ago | parent | next [-]

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

	▲	jcalvinowens 9 hours ago \| parent [-]
		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.

▲

woodruffw 9 hours ago | parent | prev [-]

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

▲

jcalvinowens 9 hours ago | parent [-]

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.

▲

woodruffw 9 hours ago | parent [-]

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.

▲

jcalvinowens 9 hours ago | parent [-]

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

▲

woodruffw 9 hours ago | parent [-]

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

▲

jcalvinowens 9 hours ago | parent [-]

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

▲

woodruffw 8 hours ago | parent [-]

I think this is an overly tendentious reading. Nobody else seems to have gotten hung up on this, because they understand that it's a policy, not an immutable law of nature.

The argument advanced in the post is IMO clear: cooldowns are a sensible default to have, and empirically seem to be effective at mitigating the risk of compromised dependencies. I thought I took sufficient pains to be clear that they're not a panacea.

▲

jcalvinowens 8 hours ago | parent [-]

I'm simply saying I think the policy you're proposing is bad. It is completely bizarre to me you're trying to frame that as a semantic argument.

▲

woodruffw 8 hours ago | parent [-]

I'm not saying it's a semantic argument. I'm saying that the policy isn't universal, whereas your argument appears to hinge on me thinking that it is. But this seems to have run its course.

	▲	jcalvinowens 7 hours ago \| parent [-]
		That's a semantic argument. Me saying your proposed policy is bad is in no way predicated on any assumption you intended it to be "universal". Quite the opposite: the last thing anybody needs at work is yet another poorly justified bullshit policy they have to constantly request an "exception" to to do their job...