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.
Dependabot version updates introduce default package cooldown
131–140 of 154 posts
Re: Dependabot version updates introduce default package cooldown
#132This 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.
Re: Dependabot version updates introduce default package cooldown
#133Earlier 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.
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
#134Re: Dependabot version updates introduce default package cooldown
#135I 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.
Re: Dependabot version updates introduce default package cooldown
#136Earlier 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.
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
#137Earlier 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…
> 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
#138Earlier 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…
(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
#139Earlier 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?
(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> 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?