Live data from Hacker News

Dependabot version updates introduce default package cooldown

github.blog

131–140 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#131
post #25

Earlier quoted context omitted.

I'm in a similar camp, I dislike how often third-party package updates get pushed out, especially given the lack of serious inspection. The reality is that each update is its own potential security issue and with supply chain attacks being all too frequent, it's not a panacea.

> The reality is that each update is its own potential security issue Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.

And that’s exactly why semantic versioning provides only an illusion of stability. This is also why ecosystems that don’t pin their versions such as floating versions that are the default in JavaScript ecosystems are so much more vulnerable from a security and a regression standpoint.

Re: Dependabot version updates introduce default package cooldown

#132
post #56

This seems to be primarily an issue with a few specific package management solutions that have suffered SCA vulnerabilities recently, not generaly across the board.

It’s foolish to feel safe because your package management solution hasn’t been attacked yet. The attack vector is generalized.

It’s rational to feel much safer in the Java packages ecosystem, where pinned versions are the default and the norm, and packages cannot run any install-time scripts.

Re: Dependabot version updates introduce default package cooldown

#133
post #78

Earlier quoted context omitted.

Every single one now will be more sneaky, and we’ll be operating on a 3-day cooldown for no reason.

How exactly does that work? I don't think that HNers understand the recent supply chain attacks very well at all. I also don't think they realize the tests the SCA/package providers do to all the major packages. Almost all these attacks try to reach out to external sites to steal your data. That is exceptionally hard to hide in any meaningful way.

That’s a bold claim to make about HNers. Au contraire, security companies have absolutely missed supply chain attacks.

Example:

https://snyk.io/blog/node-gyp-supply-chain-compromise-self-p...

Before that we had event-stream, then we had XZ compromise.

It’s not exceptionally hard to delay reaching out to external sites until after a cooldown period.

Re: Dependabot version updates introduce default package cooldown

#135

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.

[deleted]

Re: Dependabot version updates introduce default package cooldown

#136
post #125
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.

> language package managers are not [curated] Why not? Seems like exactly what is being asked for.

Curated by whom?

If you want to curate a language package manager, there's nobody stopping you. Curation is a product that can trivially be built on top of an allow-by-default platform. If you want to make "NPM, except we've vetted all the packages", you can just do that, today, and you can even make use of all the OSS packages that already exist on NPM. Your hypothesis is that people want this, would value it if it existed, and would maybe even pay for it. So what's stopping people? Anyone who hasn't thought deeply enough to answer this question doesn't have the privelige to say "just curate it, what's the problem?". Curation isn't that simple, as any distro package manager volunteer would tell you.

Re: Dependabot version updates introduce default package cooldown

#137

Earlier quoted context omitted.

I agree it's tiresome that language package managers continue to be an embarrassment. But actually your comparison is incorrect, distros are nothing like app stores. App stores are full of the same junk and malware as language package managers. Distros are vetted collections of real software that use modern best practices to secure the software supply chain.

Being unable to rotate the same weak RSA key for over a decade because it was too operationally cumbersome[1] does not strike me as “modern best practices.” I also don’t think any Linux distribution package maintainer would make a legally binding claim to have “vetted” packages: the filter is reputational, not a strong guarantee that the package is not malicious. The xz incident demonstrates that tidily: the only rea…

Two security incidents over decades is proof that distros are more secure, not less. Every other system for distributing software has weekly security issues.

> what package distribution mechanisms actually provide in terms of guarantees

1) Mirrors of cryptographically signed files to verify integrity (both the source code and the built packages), 2) a secure software supply chain & SBOM, 3) reproducible builds (for some distros), 4) humans independent of the authors vetting admittance of new packages to prevent obvious malware, 5) stable branches of packages that work together (preventing need to constantly upgrade, a source of new vulnerabilities), 6) backported security patches (necessary if you can't upgrade), 7) package maintainers fixing glaring security holes in the default installation methods of software to prevent the distro from having new vulnerabilities.

Re: Dependabot version updates introduce default package cooldown

#138

Earlier quoted context omitted.

Being unable to rotate the same weak RSA key for over a decade because it was too operationally cumbersome[1] does not strike me as “modern best practices.” I also don’t think any Linux distribution package maintainer would make a legally binding claim to have “vetted” packages: the filter is reputational, not a strong guarantee that the package is not malicious. The xz incident demonstrates that tidily: the only rea…

Two security incidents over decades is proof that distros are more secure, not less. Every other system for distributing software has weekly security issues. > what package distribution mechanisms actually provide in terms of guarantees 1) Mirrors of cryptographically signed files to verify integrity (both the source code and the built packages), 2) a secure software supply chain & SBOM, 3) reproducible builds (for s…

To be clear, the RSA key thing isn’t really about it being a security issue — that’s a part of it, but the bigger point was that it reflects structural failure/inertia that’s commonplace in distribution packaging.

(I am not a hater of distribution packaging, either. But I typically find comparisons between it and language packaging lacking, because the two have very different trust topologies.)

Re: Dependabot version updates introduce default package cooldown

#139

Earlier quoted context omitted.

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?

I gave Shai Hulud as an example above. If you want precise timeline examples that demonstrate the efficacy of cooldowns, here’s some examples I collected last year[1].

(See the “Window of opportunity” column in the table.)

[1]: https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Re: Dependabot version updates introduce default package cooldown

#140
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?

[dead]
Post reply on HN