I’m having trouble staying on top of updates for my self hosted applications and infrastructure. Not everything has auto updates baked in and some things you may not want to auto update. How do y’all handle this? How do you keep track of vulnerabilities? Are there e.g. feeds for specific applications I can subscribe to via RSS or email?
upgrade all things by default
https://github.com/topgrade-rs/topgrade/
This is also a great way to just break everything you’ve set up.
that’s a lot of FUD, topgrade just upgrades using all package managers you have, it doesn’t do the upgrades itself bypassing the manager that installed it, or package authors.
The issue is more that trying to upgrade everything at the same time is a recipe for disaster and a troubleshooting nightmare. Once you have a few interdependent services/VMs/containers/environments/hosts running, what you want to do is upgrade them separately, one at a time, then restart that service and anything that connects to it and make sure everything still works, then move on to updating the next thing.
If you do this shotgun approach for the sake of expediency, what happens is something halfway through the stack of upgrades breaks connectivity with something else, and then you have to go digging through the logs trying to figure out which piece needs a rollback.
Even more fun if two things in the same environment have conflicting dependencies, and one of them upgrades and installs its new dependency version and breaks whatever manual fix you did to get them to play nice together before, and good luck remembering what you did to fix it in that one environment six months ago.
It’s not FUD, it’s experience.
I’ve been doing that for years. Rollbacks are very rare, to the point that it doesn’t make much of a difference whether I do them all at once or not, other than spending more time to do it.
If I wasn’t using containers for everything, sure. Otherwise it’s a bit of an excessive concern.
This is a bad idea for a number of reasons. Most obvious issue is that it doesn’t guarantee anything in the way of actually fixing vulnerabilities, because some project you use may not even be scanning their own work.
what’s the alternative? Write a PR yourself?
Yup. Really easy in most cases if you’re just upgrading a dependency version of something to the next minor release up, but then it has to pass all the project CI tests, and get an actual maintainer to tag it for release. That’s how open source works though.
That may work for a handful of projects. It’d be my full time job if I did it for everything I run. Also, I might simply suggest maintainers to adopt dependabot or an alternative before I spend time with manual changes. These things should be automated.
Well a PR means an upstream fix for the project. If you want to scan all your local running things, by all means change whatever you want, but it will just be potentially wiped out by the tool you mentioned if running.
dependabot is a tool for repos, not to apply local changes
I’m aware, but then you mentioned “manual changes”, which connotes “local changes”. Putting up a PR with changes isn’t considered a manual anything.
It doesn’t. Manual as in a PR with upgrades that you’re suggesting yourself, as opposed to running dependabot.
If I have to open a PR myself, that’s very much a manual change.