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

251–260 of 287 posts

Re: We should all be using dependency cooldowns

#251

Post by michaelcampbell »

skybrian wrote: post #90
jerf wrote: post #79

Earlier quoted context omitted.

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…

It seems like some of the arguments in favor of doing frequent releases apply at least a little bit for dependency updates? Doing updates on a regular basis (weekly to monthly) seems like a good idea so you don't forget how to do them and the work doesn't pile up. Also, it's easier to debug a problem when there are fewer changes at once. But they could be rescheduled depending on what else is going on.

> Doing updates on a regular basis (weekly to monthly)

This lessens, but doesn't eliminate supply side vulns. You can still get a vulnerable new release if your schedule happens to land just after the vuln lands.

TFA proposes a _delay_ in a particular dependency being pulled in. You can still update every day/hour/microsecond if you want, you just don't get the "new" thing until it's baked a bit.

Re: We should all be using dependency cooldowns

#253

Post by [deleted] »

icehawk wrote: post #203
jcalvinowens wrote: post #53

Earlier quoted context omitted.

Zero days often get fixed sooner than seven days. If you wait seven days, you're pointlessly vulnerable.

Known vulnerabilities often get fixed sooner than seven days. You will not know how long it takes to get a zero day fixed, because zero in "zero day" ends when the vendor is informed: > "A zero day vulnerability refers to an exploitable bug in software that is unknown to the vendor."

[deleted]

Re: We should all be using dependency cooldowns

#254

Post by morshu9001 »

gbin wrote: post #128

Feels like the tragedy of the commons: I don't want to look at the change, I don't want to take responsibility, somebody else will take care or it, I just have to wait. Ok if this is an amazing advice and the entire ecosystem does that: just wait .... then what? We wait even more to be sure someone else is affected first? Every time I see people saying you need to wait to upgrade it is like you are accumulating tech…

The update tech debt tends not to compound or even accumulate at all. Usually you'd pay the same to update v1 to v2 as you would for v1 to v3. Maybe skipping v2 has a negative cost even.

Re: We should all be using dependency cooldowns

#255

Post by jcalvinowens »

saurik wrote: post #182
jcalvinowens wrote: post #106

Earlier quoted context omitted.

> The argument is not "never update quickly": it is don't routinely deploy updates constantly that are not known to be high priority fixes. Yes. I'm saying that's wrong. The default should always be to upgrade to new upstream releases immediately. Only in exceptional cases should things be held back.

But that isn't what you said? ;P "f you wait seven days, you're pointlessly vulnerable." <- this is clearly a straw man, as no one is saying you'd wait seven days to deploy THAT patch... but, if some new configuration file feature is added, or it is ported to a new architecture you aren't using--aka, the 99.99% of patches--you don't deploy THOSE patches for a while (and I'd argue seven days is way way too small) unti…

You're completely missing the point.

> this is clearly a straw man, as no one is saying you'd wait seven days to deploy THAT patch...

The policy being proposed is that upgrades are delayed. So in a company where that policy was enforced, I would be required to request an exception to the policy for your hypothetical patch.

That's unacceptable for me. That's requiring me to do extra work for a nebulous poorly quantified security "benefit". It's a waste of my time and energy.

I'm saying the whole policy is unjustified and should never be applied by default. At all. It's stupid. Its harmful for zero demonstrable benefit.

I'm being blunt because you seem determined to somehow misconstrue what I'm saying as a nitpicky argument. I'm saying the whole policy is terrible and stupid. If it were forced on me by an employer, I would quit. Seriously.

Re: We should all be using dependency cooldowns

#256

Post by jazzyjackson »

patrick451 wrote: post #247
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…

Jumping straight to the new release because it fixed one security bug has always struck me as a round about way of trying to achieve security through obscurity, especially when the releases include tons of other changes. Yes, this release fixed CVE-123, but how many new ones were added?

This is a valid security strategy tho, always shifting the ground beneath the attackers feet. As the code author, you might not know where there are vulnerabilities in your code, but someone targeting you does. You will never have bug free code, so better to just keep it in constant flux than allow an attacker to analyze an unchanging application over months and years.

Re: We should all be using dependency cooldowns

#258

Post by snowwrestler »

When I admin’ed a bunch of Wordpress and Drupal websites (open source CMSes), I was very quick to install security patches, and relatively slow to install normal updates—for this reason.

It’s one of the main reasons I used popular open source software: so I could ride the coattails of the rest of the community. Basically everyone else could be my beta tester.

A regular update was an input to the community security practice, so I would let it settle for a while. A security patch was an output of the community security practice, so I would install ASAP, even if it meant breaking a feature temporarily.

I also manually managed dependencies as commits to the main codebase, meaning my entire site was one deployable object from a single Git repo. The “modern” practice today seems to instead favor a minimal repo and resolving and pulling dependencies at deploy time. Personally I think this is a bad idea that has amplified the risk of supply chain attacks.

And now the idea is apparently back to: give it a little while. Tell the automatic dependency puller to chill out and wait.

Re: We should all be using dependency cooldowns

#259

Post by jbkgujklgui »

cesarb wrote: post #183
DrScientist wrote: post #47

The think I find most odd about the constant pressure to update to the most recent and implied best version is that there is some implicit belief that software get's uniformly better with each release. Bottom line those security bugs are not all from version 1.0 , and when you update you may well just be swapping known bugs for unknown bugs. As has been said elsewhere - sure monitor published issues and patch if need…

> Bottom line those security bugs are not all from version 1.0, and when you update you may well just be swapping known bugs for unknown bugs. One great example of that is log4shell. If you were still using version 1.0 (log4j 1.x), you were not vulnerable, since the bug was introduced in version 2.0 (log4j 2.x). There were some known vulnerabilities in log4j 1.x, but the most common configuration (logging only to a l…

The infamous log4j vulnerability was actually a feature when it was introduced. It was only several years later it was considered a security vulnerability. Countless of other techs has had the same problem, for example, ActiveX. Same with most downgrade attacks, they were most often considered a good thing (better compatibility) when introduced, only much later were such features considered non-good.

Re: We should all be using dependency cooldowns

#260

Post by skybrian »

michaelcampbell wrote: post #251
skybrian wrote: post #90

Earlier quoted context omitted.

It seems like some of the arguments in favor of doing frequent releases apply at least a little bit for dependency updates? Doing updates on a regular basis (weekly to monthly) seems like a good idea so you don't forget how to do them and the work doesn't pile up. Also, it's easier to debug a problem when there are fewer changes at once. But they could be rescheduled depending on what else is going on.

> Doing updates on a regular basis (weekly to monthly) This lessens, but doesn't eliminate supply side vulns. You can still get a vulnerable new release if your schedule happens to land just after the vuln lands. TFA proposes a _delay_ in a particular dependency being pulled in. You can still update every day/hour/microsecond if you want, you just don't get the "new" thing until it's baked a bit.

Yes, understood. Not arguing against cooldowns.
Post reply on HN