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

61–70 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#61

Post by [deleted] »

brikym wrote: post #57
zihotki wrote: 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.

When you're running from a bear on a hiking trip you just have to be faster than your friend. So just set your cooldown slightly longer than everyone else's cooldowns. The cooldown will give security researchers some time to scan the packages so it's still good.

[deleted]

Re: Dependabot version updates introduce default package cooldown

#62

Post by zarzavat »

bitmasher9 wrote: post #59
kibwen wrote: 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.

They are literally solving the same problem, it’s just that distro packages operate on a lower level and thus receive more scrutiny. There have been plenty of examples of poisoned Linux packages, both at the source level and at the package level.

A distro package manager provides access to a small set of packages that the distro thinks you might like. A language package manager provides access to the full set of packages. The language level package manager is solving a more ambitious problem.

Distro package managers don't solve the problem they just punt on it, saying "you can add an unofficial source but you're on your own to maintain security". I agree with GP that the comparison is tiresome.

Re: Dependabot version updates introduce default package cooldown

#63

Post by moralestapia »

woodruffw wrote: post #27
zihotki wrote: 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.

> But if everyone will be delaying updates, won't be there less chances to catch it in time? No: the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized. Three days is a short cooldown, but it should be a good enough lead for scanning parties. > I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require. It…

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

Re: Dependabot version updates introduce default package cooldown

#64

Post by 0cf8612b2e1e »

333c wrote: post #38
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 feel the same. So so so many "regular expression denial-of-service" issues at my last job that just didn't seem serious or often reachable.

All of my services are internal, yet I am continually getting red alerts that there is a novel denial-of-service that needs to be patched immediately.

Re: Dependabot version updates introduce default package cooldown

#65

Post by 0cf8612b2e1e »

ashu1461 wrote: post #46
madeofpalk wrote: post #8

Earlier quoted context omitted.

What would be a security measure that should only be selectively enforced?

There are few ideas which come to my mind, some might be far fetched, taking NPM as an example. - Restricting packages with similar names as of popular packages restrict expres because express is a popular package. - Imposing stricter 2FA checks on accounts of authors of these packages. - Making sure that published packages don't have vulnerabilities and clear npm audit. - Alerts in case these packages contain a depe…

Pre-publish to official security orgs. Does not get released into the wild until k of N auditors agree.

Re: Dependabot version updates introduce default package cooldown

#66

Post by cmckn »

zihotki wrote: 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.

Re: Dependabot version updates introduce default package cooldown

#67

Post by bitmasher9 »

zarzavat wrote: post #62
bitmasher9 wrote: post #59

Earlier quoted context omitted.

They are literally solving the same problem, it’s just that distro packages operate on a lower level and thus receive more scrutiny. There have been plenty of examples of poisoned Linux packages, both at the source level and at the package level.

A distro package manager provides access to a small set of packages that the distro thinks you might like. A language package manager provides access to the full set of packages. The language level package manager is solving a more ambitious problem. Distro package managers don't solve the problem they just punt on it, saying "you can add an unofficial source but you're on your own to maintain security". I agree with…

Debian stable has over 69,000 packages, which is more then some languages have…

Re: Dependabot version updates introduce default package cooldown

#68

Post by klausa »

moralestapia wrote: post #63
woodruffw wrote: post #27

Earlier quoted context omitted.

> But if everyone will be delaying updates, won't be there less chances to catch it in time? No: the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized. Three days is a short cooldown, but it should be a good enough lead for scanning parties. > I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require. It…

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

Analysis and detection are not the same.

Re: Dependabot version updates introduce default package cooldown

#69

Post by dwoldrich »

skissane wrote: post #44
dwoldrich wrote: post #20

Earlier quoted context omitted.

For libraries, I like the Gnu Affero Public License[1]. If you run the library in software with that license, you have to publish all the source of the entire project that incorporates it. No corporation could tolerate this, though, so the library vendor can negotiate a commercial license of their software for appropriate fees. That said, corporations are not going to want to negotiate fees with 100's of vendors over…

> This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. I don't think this idea is going to go anywhere. If a package is available for free, on convenient licensing terms, developers will use it. If y…

I don't disagree with you that freely distributed software on conveniently licensed terms is going to be the go-to stance for the majority of solo and non-commercial developers.

I just believe I could arrange the universe such that I get to have my cake (commercial licensing) and eat it too (with default open source licensing).

It is my experience that corporations do pay handsomely for software they use, even SaaS ones as the cost of doing business. Open source communities need mechanisms for funding that are consistent and low friction.

This is why the software language/repository/platform itself needs to facilitate license tracking and billing for alternative commercial licenses, to make it easy for corporations.

A successful new language effort that provides this facility need not be an enforcer except to say if an enterprise is willing and signed up to pay for any dependencies it uses, it is obligated to pay for all of them with something like AGPL 3 as the poison pill they have to swallow otherwise if they distribute or serve from any copyleft software.

Having simple, consistent rules that vendors and consumers have to follow with no rugpulls will be important for market acceptance. Having voluntary compliance with license terms will also be important to not turn people off from the ecosystem and to let them kick the tires. If software vendors want to distribute only unencumbered free and open source, then god bless 'em, they should be able to do it.

Re: Dependabot version updates introduce default package cooldown

#70

Post by stingraycharles »

bitmasher9 wrote: post #59
kibwen wrote: 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.

They are literally solving the same problem, it’s just that distro packages operate on a lower level and thus receive more scrutiny. There have been plenty of examples of poisoned Linux packages, both at the source level and at the package level.

> They are literally solving the same problem

No they’re not. Distro packages cater to end users and have very different release cycles and maintenance processes.

Distro packages are managed top-down (pushed by maintainers), while language packages are managed bottom-up (pushed by authors), so to say.

Post reply on HN