Live data from Hacker News

Dependabot version updates introduce default package cooldown

github.blog

111–120 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#111
post #66
post #15

If everyone starts applying cooldowns, won't it postpone the problem? So now there is a considerable amount of users who are affected and someone from the affected group discovers the infection and reports it. But if everyone will be delaying updates, won't be there less chances to catch it in time? I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.

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.

The way to guarantee that is to pay one of those cybersecurity firms, that's basically their business.

And the most effective strategy is to audit and review your dependencies and any updates to them. That probably constrains how many you can have, but just minimizing them is reducing the size of the target, not protecting it per se.

Re: Dependabot version updates introduce default package cooldown

#112

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.

It's essentially blowback from the number-one security problem being out of date software with known vulnerabilities. It's also easy to measure without deeper knowledge of the system, so it gets focused on to the detriment of strategies based on deeper analysis and reducing overall attack surface.

Re: Dependabot version updates introduce default package cooldown

#113
post #54

Earlier quoted context omitted.

And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one. This assumes that they employ clandestine enough techniques that you have to actually install, wait and observe the behavior for longer than the cooldown period in order to detect this, because the code is "obfuscated" enough to evade static analysis of the code. It's anti-virus / anti-anti…

Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further…

A package I maintain once ended up in exactly this state because of a sync script.

Re: Dependabot version updates introduce default package cooldown

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

The publishing topology is pretty fundamentally different: the entire power (and danger) of language package managers is that anybody can publish, not just a privileged few. (This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)

Why not to create a separate list of verified package versions for most popular packages, AKA «stable» channel?

Use stable channel for typical packages, use bleeding edge channel for some specific packages only.

Re: Dependabot version updates introduce default package cooldown

#115

Earlier quoted context omitted.

I think that’s a difference in implementation details, not a difference in what it fundamentally is. I’m not arguing that there aren’t differences between the two, I’m arguing that they are fundamentally the same solution (gather all of the software in one location with) to same problem (how can I safely download some software).

They are very fundamentally different solutions: the entire premise of distribution packaging is that you’re relying on some distribution maintainer’s discretion. It’s not an open index.

This is exactly what users wants in this case: someone need to check a package and mark it as safe to use.

Re: Dependabot version updates introduce default package cooldown

#116

Earlier quoted context omitted.

The publishing topology is pretty fundamentally different: the entire power (and danger) of language package managers is that anybody can publish, not just a privileged few. (This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)

Why not to create a separate list of verified package versions for most popular packages, AKA «stable» channel? Use stable channel for typical packages, use bleeding edge channel for some specific packages only.

> verified package versions

Who is doing this verification?

Re: Dependabot version updates introduce default package cooldown

#117

Earlier quoted context omitted.

Why not to create a separate list of verified package versions for most popular packages, AKA «stable» channel? Use stable channel for typical packages, use bleeding edge channel for some specific packages only.

> verified package versions Who is doing this verification?

And then who watches the watchmen? Chains of authority can always be questioned. I think GP is suggesting that the package management platforms themselves provide the verification if they want to stay in the business of being the de facto source.

Re: Dependabot version updates introduce default package cooldown

#118

Earlier quoted context omitted.

Do you have an example of those things you're alleging? All package malware related news I see are related to users being affected by it (then security firms do their analysis whatever) ...

If you google “supply chain security company” you will find various companies of various reputations vying for attention in this space.

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.

Re: Dependabot version updates introduce default package cooldown

#119

Earlier quoted context omitted.

If you google “supply chain security company” you will find various companies of various reputations vying for attention in this space.

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.

Re: Dependabot version updates introduce default package cooldown

#120
post #31
post #30

Earlier quoted context omitted.

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.

Give it two years.

Two years until... what, exactly?
Post reply on HN