| ▲ | wrs 10 hours ago |
| 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. |
|
| ▲ | ktpsns 10 hours ago | parent | next [-] |
| Unattended upgrades for server installations are very common. For instance, for Ubuntu/Debian this updates by default daily (source: https://documentation.ubuntu.com/server/how-to/software/auto...). No cooldown implemented, AFAIK. Of course we talk about OS security upgrades here, not library dependencies. But the attack vector is similar. |
|
| ▲ | jcalvinowens 10 hours ago | parent | prev | next [-] |
| 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 since. |
| |
| ▲ | smaudet 10 hours ago | parent | next [-] | | > 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. | | |
| ▲ | jcalvinowens 9 hours ago | parent [-] | | My codebase runs on top of the same millions of lines of decades old system code that yours does. You don't seem to appreciate that :) | | |
| ▲ | smaudet 9 hours ago | parent [-] | | If you mean operating system code, that is generally opaque, and not quite what the article is talking about (you don't use a dependency manager to install code that you have reviewed to perform operating system updates - you can, and that is fantastic for you, but not I imagine what you mean). Although, even for Operating Systems, cooldown periods on patches are not only a good thing, but something that e.g. a large org that can't afford downtime will employ (managing windows or linux software patches, e.g.). The reasoning is the same - updates have just as much chance to introduce bugs as fix them, and although you hope your OS vendor does adequate testing, especially in the case where you cannot audit their code, you have to wait so that either some 3rd party security vendor can assess system safety, or you are able to perform adequate testing yourself. |
|
| |
| ▲ | icehawk 9 hours ago | parent | prev | next [-] | | > 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. I think you're using a different definition of zero day than what is standard. Any zero day vulnerability is not going to have a patch you can get with an update. | | |
| ▲ | jcalvinowens 9 hours ago | parent [-] | | Zero days often get fixed sooner than seven days. If you wait seven days, you're pointlessly vulnerable. | | |
| ▲ | saurik 8 hours ago | parent [-] | | Only if you already upgraded to the one with the bug in it, and then only if you ignore "this patch is actually different: read this notice and deploy it immediately". The argument is not "never update quickly": it is don't routinely deploy updates constantly that are not known to be high priority fixes. | | |
| ▲ | jcalvinowens 7 hours ago | parent [-] | | > The argument is not "never update quickly": it is don't routinely deploy updates constantly that are not known to be high priority fixes. Yes. I'm saying that's wrong. The default should always be to upgrade to new upstream releases immediately. Only in exceptional cases should things be held back. | | |
| ▲ | saurik 2 hours ago | parent | next [-] | | But that isn't what you said? ;P "f you wait seven days, you're pointlessly vulnerable." <- this is clearly a straw man, as no one is saying you'd wait seven days to deploy THAT patch... but, if some new configuration file feature is added, or it is ported to a new architecture you aren't using--aka, the 99.99% of patches--you don't deploy THOSE patches for a while (and I'd argue seven days is way way too small) until you get a feel that it isn't a supply chain attack (or what will become a zero day). Every now and then, someone tries to fix a serious bug... most of the time, you are just rolling the die on adding a new bug that someone can quickly find and exploit you using. | |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
|
|
| |
| ▲ | starburst 9 hours ago | parent | prev [-] | | Upgrading to new version can also introduce new exploits, no amount of tests can find those. Some of these can be short-lived, existing only on a minor patch and fixed on the next one promptly but you’ll get it if you upgrade constantly on the latest blindly. There is always risks either way but latest version doesn’t mean the “best” version, mistakes, errors happens, performance degradation, etc. | | |
| ▲ | jcalvinowens 9 hours ago | parent [-] | | Personally, I choose to aggressively upgrade and engage with upstreams when I find problems, not to sit around waiting and hoping somebody will notice the bugs and fix them before they affect me :) | | |
|
|
|
| ▲ | midasz 10 hours ago | parent | prev | next [-] |
| Renovate (dependabot equiv I think) creates PRs, I usually walk through them every morning or when there's a bit of downtime. Playing with the idea to automerge patches and maybe even minor updates but up until now it's not that hard to keep up. |
|
| ▲ | jerlam 10 hours ago | parent | prev [-] |
| Your CI/CD might be setup to upgrade all your dependencies on every build. |
| |
| ▲ | wrs 10 hours ago | parent [-] | | 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! | | |
|
