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

Dependabot version updates introduce default package cooldown

github.blog

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#121

Post by Kudos »

JoshTriplett wrote: post #42
Waterluvian wrote: post #18

I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.

> I’m convinced that updating so much more often is worse, not better. The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity t…

I've seen a similar benefit enforcing a 1 year instead of 3 year TLS cert lifetime limit in the past. It forces more automation and stronger processes.

Re: Dependabot version updates introduce default package cooldown

#122

Post by Waterluvian »

jjmarr wrote: post #72
Waterluvian wrote: post #52

Earlier quoted context omitted.

My logical read of the situation is that I end up making fewer overall changes if I end up upgrading a dependency once, not thrice, to a specific version. And the changes are their own source of risk.

In reality, one massive update is too big to digest and it never happens. So you're stuck on out-of-date packages having lost the ability to update. That's never a problem until it suddenly is. Company is put at significant risk (courts want to reason by analogy and "engineers skipped maintenance and endangered people" is an easy one) and nobody is to blame since nobody owned the task.

Except I’ve been doing it this way for years and it’s not actually a real problem. Just an imagined one.

Re: Dependabot version updates introduce default package cooldown

#123

Post by moralestapia »

woodruffw wrote: post #119
moralestapia wrote: post #118

Earlier quoted context omitted.

Didn't find any. Found a lot scammers, though. Just post one link of a "supply chain" problem that was prevented by any of these companies before it went into the wild and affected users. Simple.

I generally try not to name the companies directly, because I don’t want to give them free advertising. But you can look up e.g. the recent Shai Hulud campaign. > Just post one link of a "supply chain" problem that was prevented by any of these companies before it went into the wild and affected users. This is not the claim being made, since cooldowns are not widely adopted at the moment.

I see. So, it has never happened before.

Re: Dependabot version updates introduce default package cooldown

#124

Post by MeetingsBrowser »

gizzlon wrote: post #91
MeetingsBrowser wrote: post #37

Earlier quoted context omitted.

Requires a GitHub security advisory and > Only advisories reviewed by GitHub trigger alerts. From https://docs.github.com/en/code-security/concepts/supply-cha...

So it forces everyone to use more GitHub stuff? Maybe I'm misunderstanding, but this means I now need to submit to GitHub Security Advisor to get my security fix out ASAP?

Nothing changed here and it seems reasonable to me.

If you want GitHub to tell people about your security fix, someone needs to tell GitHub about the fix first.

AFAIK they mostly pull from the normal sources like NVD automatically, but you can also submit to GitHub directly.

Re: Dependabot version updates introduce default package cooldown

#125

Post by moring »

kibwen wrote: post #30
noosphr wrote: post #26

Watching language package managers reinvent everything distribution package managers have been doing since the 90s has been as fun as watching crypto people reinvent financial regulation.

This comparison is tiresome. Distro package managers are curated, language package managers are not. They're serving completely different use cases; the former is the App Store, the latter is the web.

> language package managers are not [curated]

Why not? Seems like exactly what is being asked for.

Re: Dependabot version updates introduce default package cooldown

#126

Post by swiftcoder »

pixl97 wrote: post #77
cmckn wrote: post #66

Earlier quoted context omitted.

I agree, it’s just the wrong approach. As a user, there’s no way to know if a package has been audited during the cooldown by some generous cybersecurity firm before you pull it in, it’s just wishful thinking. Minimizing your dependencies is a more effective strategy against supply chain attacks.

Hence by writing your own code with its own set of vulns to be detected.

Unless you are a big enough target, there is still potential value to this. Is your business worth enough for someone to spend a lot of money hunting bespoke vulnerabilities? If not, your main risk is being swept in a vulnerability affecting a common dependency, and eliminating the common dependencies removes that risk.

Re: Dependabot version updates introduce default package cooldown

#127

Post by woodruffw »

moralestapia wrote: post #123
woodruffw wrote: post #119

Earlier quoted context omitted.

I generally try not to name the companies directly, because I don’t want to give them free advertising. But you can look up e.g. the recent Shai Hulud campaign. > Just post one link of a "supply chain" problem that was prevented by any of these companies before it went into the wild and affected users. This is not the claim being made, since cooldowns are not widely adopted at the moment.

I see. So, it has never happened before.

Well, yeah. There’s no package police that’ll stop you from installing malware. The argument has never revolved around that; the argument is solely that cooldowns are effective if you use them, and timely detection by third parties is strong evidence of that.

Re: Dependabot version updates introduce default package cooldown

#128

Post by moralestapia »

woodruffw wrote: post #127
moralestapia wrote: post #123

Earlier quoted context omitted.

I see. So, it has never happened before.

Well, yeah. There’s no package police that’ll stop you from installing malware. The argument has never revolved around that; the argument is solely that cooldowns are effective if you use them, and timely detection by third parties is strong evidence of that.

>and timely detection by third parties is strong evidence of that

Do you have an example of those things you're alleging?

Re: Dependabot version updates introduce default package cooldown

#129

Post by bunderbunder »

Waterluvian wrote: post #122
jjmarr wrote: post #72

Earlier quoted context omitted.

In reality, one massive update is too big to digest and it never happens. So you're stuck on out-of-date packages having lost the ability to update. That's never a problem until it suddenly is. Company is put at significant risk (courts want to reason by analogy and "engineers skipped maintenance and endangered people" is an easy one) and nobody is to blame since nobody owned the task.

Except I’ve been doing it this way for years and it’s not actually a real problem. Just an imagined one.

I think that’s the response the “it’s never a real problem until suddenly it is” observation was trying to head off.

There’s always someone who doesn’t want to take the advice of all the people who’ve been burned because “well it’s never happened to me.” I used to be that someone myself. Until the day it happened to me.

Re: Dependabot version updates introduce default package cooldown

#130

Post by yearolinuxdsktp »

JoshTriplett wrote: post #42
Waterluvian wrote: post #18

I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.

> I’m convinced that updating so much more often is worse, not better. The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity t…

Delaying non-security updates has the benefit of not wasting a team’s time when something regresses and is fixed in a quick follow up patch. Having to report issues upstream is not free.
Post reply on HN