Live data from Hacker News

We should all be using dependency cooldowns

blog.yossarian.net

21–30 of 287 posts

Re: We should all be using dependency cooldowns

#21
post #6

Earlier quoted context omitted.

Do you upgrade all your dependencies every day ? If not, then there’s no real difference in upgrading as if it were 7 days ago.

I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs…

> zero day is going to bite you in the ass

Maybe your codebase is truly filled with code that is that riddled with flaws, but:

1) If so, updating will not save you from zero days, only from whatever bugs the developers have found.

2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them.

3) In the case where a real issue is found, I can't imagine it isn't hard to use the aforementioned security vendors, and use their recommendations to force updates outside of a cooldown period.

Re: We should all be using dependency cooldowns

#22
I think there’s a much stronger argument for policies that both limit the number and complexity of dependencies. Don’t add it unless it’s highly focused (no “everything libraries” that pull in entire universes of their own) and carries a high level of value. A project’s entire dependency tree should be small and clean.

Libraries themselves should perhaps also take a page from the book of Linux distributions and offer LTS (long term support) releases that are feature frozen and include only security patches, which are much easier to reason about and periodically audit.

Re: We should all be using dependency cooldowns

#23
The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass.

It's a shame some ecosystems move waaay too fast, or don't have a good story for having distro-specific packages. For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects. I might be wrong.

Re: We should all be using dependency cooldowns

#25
I wonder if LLMs can help here to some extent. I agree with others that cooldowns aren't helpful if everyone is doing it.

I've been working on automatic updates for some of my [very overengineered] homelab infra and one thing that I've found particularly helpful is to generate PRs with reasonable summaries of the updates with an LLM. it basically works by having a script that spews out diffs of any locks that were updated in my repository, while also computing things like `nix store diff-closures` for the before/after derivations. once I have those diffs, I feed them into claude code in my CI job, which generates a pull request with a nicely formatted output.

one thing I've been thinking is to lookup all of those dependencies that were upgraded and have the LLM review the commits. often claude already seems to lookup some of the commits itself and be able to give a high level summary of the changes, but only for small dependencies where the commit hash and repository were in the lock file.

it would likely not help at all with the xz utils backdoor, as IIRC the backdoor wasn't even in the git repo, but on the release tarballs. but I wonder if anyone is exploring this yet?

Re: We should all be using dependency cooldowns

#26
Some scattered thoughts on that:

* If everybody does it, it won't work so well

* I've seen cases where folks pinned their dependencies, and then used "npm install" instead of "npm ci", so the pinning was worthless. Guess they are the accidental, free beta testers for the rest of us.

* In some ecosystems, distributions (such as Debian) does both additional QA, and also apply a cooldown. Now we try to retrofit some of that into our package managers.

Re: We should all be using dependency cooldowns

#27

The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass. It's a shame some ecosystems move waaay too fast, or don't have a good story for having distro-specific packages. For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects. I might be wro…

It is possible to work with rust, using debian repositories as the only source.

Re: We should all be using dependency cooldowns

#28
post #4

> we should all Except if everyone does it chance of malicious things being spotted in source also drops by virtue of less eyeballs Still helps though in cases where maintainer spot it etc

> also drops by virtue of less eyeballs

I don't think the people automatically updating and getting hit with the supply chain attack are also scanning the code, I don't think this will impact them much.

If instead, updates are explicitly put on cooldowns, with the option of manually updating sooner, then there would be more eyeballs, not fewer, as people are more likely to investigate patch notes, etc., possibly even test in isolation...

Re: We should all be using dependency cooldowns

#30
post #17
post #11

Earlier quoted context omitted.

Your CI/CD might be setup to upgrade all your dependencies on every build.

I’ve seen a lot of CI/CD setups and I’ve never seen that. If that were common practice, it would certainly simplify the package manager, since there would be no need for lockfiles!

I didn't necessarily say they were good CI/CD practices.
Post reply on HN