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

91–100 of 287 posts

Re: We should all be using dependency cooldowns

#91

Post by jcalvinowens »

saurik wrote: post #84
jcalvinowens wrote: post #68

Earlier quoted context omitted.

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

If your internal process is willing to ship and deploy upgrades--whether to your code or that of a third party--without testing even so minimally to notice that they cause almost a 100% chance of crashing, you need the advice to slow down your updates more than anyone...

Obviously, they caught the bug and didn't deploy it.

The point is that a change to a completely unrelated component caused a latent bug to make the device unusable, ended up delaying a release for weeks and causing them have to pay me a bunch of money to fix it for them.

If they'd been applying upgrades, they would have never even known it existed, and all that trouble would have been avoided.

I mean, I'm sort of working against my own interest here: arguably I should want people to delay upgrades so I can get paid to backport things for them :)

Re: We should all be using dependency cooldowns

#92

Post by woodruffw »

compumike wrote: post #85

There's a tradeoff and the assumption here (which I think is solid) is that there's more benefit from avoiding a supply chain attack by blindly (by default) using a dependency cooldown vs. avoiding a zero-day by blindly (by default) staying on the bleeding edge of new releases. It's comparing the likelihood of an update introducing a new vulnerability to the likelihood of it fixing a vulnerability. While the article…

Yep, that's definitely the assumption. However, I think it's also worth noting that zero-days, once disclosed, do typically receive advisories. Those advisories then (at least in Dependabot) bypass any cooldown controls, since the thinking is that a known vulnerability is more important to remediate than the open-ended risk of a compromised update.

> I'm sure the majority of bugs and vulnerabilities were never supply chain attacks: they were just ordinary bugs introduced unintentionally in the normal course of software development.

Yes, absolutely! The overwhelming majority of vulnerabilities stem from normal accidental bug introduction -- what makes these kinds of dependency compromises uniquely interesting is how immediately dangerous they are versus, say, a DoS somewhere in my network stack (where I'm not even sure it affects me).

Re: We should all be using dependency cooldowns

#93

Post by jcalvinowens »

woodruffw wrote: post #82
jcalvinowens wrote: post #74

Earlier quoted context omitted.

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

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

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.

Re: We should all be using dependency cooldowns

#94

Post by switchbak »

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…

I remember this used to actually be the case, but that was many moons ago when you'd often wait a long time between releases. Or maybe the quality bar was lower generally, and it was just easier to raise it?

These days it seems most software just changes mostly around the margins, and doesn't necessarily get a whole lot better. Perhaps this is also a sign I'm using boring and very stable software which is mostly "done"?

Re: We should all be using dependency cooldowns

#95

Post by xmodem »

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've seen this argument made frequently. It's clearly a popular sentiment, but I can't help feel that it's one of those things that sounds nice in theory if you don't think about it too hard. (Also, cards on the table, I personally really like being able to pull in a tried-and-tested implementation of code to solve a common problem that's also used by in some cases literally millions of other projects. I dislike having to re-solve the same problem I have already solved elsewhere.)

Can you cite an example of a moderately-widely-used open source project or library that is pulling in code as a dependency that you feel it should have replicated itself?

What are some examples of "everything libraries" that you view as problematic?

Re: We should all be using dependency cooldowns

#97

Post by dbdr »

cxr wrote: post #34

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…

Doesn't vendoring solve the supply chain issue in the same way as picking a dependency version and never upgrading would? (especially if your package manager includes a hash of the dependency in a lock file)

Re: We should all be using dependency cooldowns

#98

Post by xmodem »

buu700 wrote: post #83
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 think AI nudges the economics more in this direction as well. Adding a non-core dependency has historically bought short-term velocity in exchange for different long-term maintenance costs. With AI, there are now many more cases where a first-party implementation becomes cheaper/easier/faster in both the short term and the long term. Of course it's up to developers to weigh the tradeoffs and make reasonable choices…

Let's have AI generate the same vulnerable code across hundreds of projects, most of which will remain vulnerable forever, instead of having those projects all depend on a central copy of that code that can be fixed and distributed once the issue gets discovered. Great plan!

Re: We should all be using dependency cooldowns

#99

Post by buu700 »

xmodem wrote: post #98
buu700 wrote: post #83

Earlier quoted context omitted.

I think AI nudges the economics more in this direction as well. Adding a non-core dependency has historically bought short-term velocity in exchange for different long-term maintenance costs. With AI, there are now many more cases where a first-party implementation becomes cheaper/easier/faster in both the short term and the long term. Of course it's up to developers to weigh the tradeoffs and make reasonable choices…

Let's have AI generate the same vulnerable code across hundreds of projects, most of which will remain vulnerable forever, instead of having those projects all depend on a central copy of that code that can be fixed and distributed once the issue gets discovered. Great plan!

You're attacking a straw man. No one said not to use dependencies.

Re: We should all be using dependency cooldowns

#100

Post by JoshTriplett »

dap wrote: post #86
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…

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

> I'm now on a team that uses Rust, where knowing that the program compiles and passes all tests gives us a lot of confidence in the update.

That's been my experience as well. In addition, the ecosystem largely holds to semver, which means a non-major upgrade tends to be painless, and conversely, if there's a major upgrade, you know not to put it off for too long because it'll involve some degree of migration.

Post reply on HN