Live data from Hacker News

Dependabot version updates introduce default package cooldown

github.blog

91–100 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#91
post #11

> The default applies only to version updates. Security updates still open immediately, so critical fixes are never delayed. does this require a real vulnerability report, or CVE? if the package is compromised would they just be able to push a false "critical update" that bypasses this wait?

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?

Re: Dependabot version updates introduce default package cooldown

#92
post #90

Earlier quoted context omitted.

If it is about a few highly specialized firms finding the vulns we should let them do it before publication and we do not need cooldowns. If it is not about that and we still subscribe to Linus's law then cooldowns will just postpone the problem.

Publishing publicly then applying cooldowns in projects is much easier tgan establishing a new standard for pre-release security testing versions that works across ecosystems and gains zooling support.

Exactly this. The firms can follow the standard practices of the industry without needing to injection further process into the projects.

Re: Dependabot version updates introduce default package cooldown

#93

Earlier quoted context omitted.

I don’t understand how they aren’t both generalized to “distributes software with versioning at a large scale”

The difference comes from the fact distro maintainers choose the software they package, while language maintainers largely don't. For example, how do you prevent somebody from phishing/typosquatting users with a package named similarly to a popular one? For distro maintainers the answer is simple - don't package it. Debian is unlikely to add a "f1refox" package. Language maintainers don't have that luxury.

Oh what?? Most package managers do try to prevent typo squatting!! Your insistence that there’s something fundamentally different between different package managers is just weird! Debian, as npm, lets you package and distribute software. The differences between them are related to policy preferences but the basic idea is the same!

Re: Dependabot version updates introduce default package cooldown

#94

Earlier quoted context omitted.

The difference comes from the fact distro maintainers choose the software they package, while language maintainers largely don't. For example, how do you prevent somebody from phishing/typosquatting users with a package named similarly to a popular one? For distro maintainers the answer is simple - don't package it. Debian is unlikely to add a "f1refox" package. Language maintainers don't have that luxury.

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.

Re: Dependabot version updates introduce default package cooldown

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

If you currently use a 7 day cooldown on a 0 day default. You can just use a 10 day cooldown on a 3 day default. But don't tell anyone...

Re: Dependabot version updates introduce default package cooldown

#96

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…

For most things in life that hit us periodically, we try to buffer them into manageable amounts so that when we address them, we do them all at once, benefiting from “economy of scale”, instead of having to constantly work on addressing everything that comes our way immediately. With package updates, however, another consideration is security: the longer you wait to release a security update, the more users may be vulnerable to it.

There’s no right answer. Every case is different, trying to impose a single rule for everyone just simplifies things beyond what is reasonable.

Re: Dependabot version updates introduce default package cooldown

#97

Earlier quoted context omitted.

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…

69,000 sounds like a lot, but it's still missing maybe 30% of the packages I want to install.

Re: Dependabot version updates introduce default package cooldown

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

Easy, then you just delay your project’s dependency updates just a little more than everyone else

The cooldowns should probably be randomised.

Re: Dependabot version updates introduce default package cooldown

#99
post #38

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.

I keep getting things like "denial of service when the SCSS or whatever parse is given malicious input”. Great, that's part of the build chain, all of its inputs are stuff we control. Why do we care.

Re: Dependabot version updates introduce default package cooldown

#100
post #90

Earlier quoted context omitted.

If it is about a few highly specialized firms finding the vulns we should let them do it before publication and we do not need cooldowns. If it is not about that and we still subscribe to Linus's law then cooldowns will just postpone the problem.

Publishing publicly then applying cooldowns in projects is much easier tgan establishing a new standard for pre-release security testing versions that works across ecosystems and gains zooling support.

Releasing secure software is the right thing to do. We only release insecure software because we need the eyeballs to make it secure.

If we believe the point made above that the many eyeballs are not that important then releasing before we have done everything to make the software as secure as possible is irresponsible.

Post reply on HN