On the other hand, occasionally security updates will be surfaced as a patch file and you're waiting on the package managers. At least if you build it yourself you have the option of applying patches.
Sure there's a tradeoff, but for most people it's really rare to use software that isn't being actively maintained. So let the maintainers update their dependencies when there's a security flaw, the auto-update will pull in the changes, and I'll still benefit from OS X's 30-second install process.
Yes. You should still keep your eye out on patches. If a big vulnerability gets patched requiring a reboot, you'll want to attend to the upgrades yourself.
I agree with never using latest, but disagree with the use of `major.minor` over `major.minor.patch`. Subscribe to all of your core dependencies release/security notes (OS, language, framework) and bump to the most recent patch versions as soon as possible. This gets you in the habit of updating dependencies regularly which is one of the most important things to do when trying to run secure services.
Of course if they need to be manually updated, there's a strong likelihood that they are using vastly outdated versions of their dependencies. Users could be wide open to unpatched exploits.
This has always been true, and also true for those that stick to LTS. If you want to receive security patches, you need to update your JDK. BTW, as the new deployment approach is to create a custom minimal runtime and bundle it with your app, your application may not need security patches, depending on what it does.
What I'm worried about is that it will be hard to avoid these security patches when you don't need them. Say you have a non-virtualized, non-shared server that only runs your own trusted code. I don't want to be forced to pay the performance penalty but it might be unavoidable without resorting to maintaining your own linux fork.
There’s something to be said for being on the oldest minor version that still receives patch releases (usually the LTS if there is such a thing). Unfortunately most FOSS libraries don’t have the luxury/resources to support parallel releases. So to get security fixes you need to keep somewhat up to date with other changes.
The worst place to be is having to fix a CVE in a hurry, but first having to upgrade your framework a few major versions including fixing some breaking API changes. I’d rather pay a small tax every month than have to risk those late nights.
Dependabot is great here, you can get updates for free, or at least preview if they are going to pass all your tests.
Let's not forget that each security fix made to Open Source software is also a recipe on how to pwn people who didn't update to that fix yet. A project changelog is in part a list of holes that can be exploited.
Security patches don't necessarily affect uptime. For example, patching and replacing e.g. libc on a live system is entirely possible, even though it's not the standard procedure.
Great and now I have to also track security updates and ship those for all my dependencies. libcurl is a great example with a release cycle of 2(!) months and tons of vulnerabilities being fixed each time.
Pride can be fleeting. There's certainly advantages and disadvantages to depending on security patches from a paid organization and from volunteers. Regardless of which OS you use, you will need one that regularly patches its vulnerabilities.
There is some beauty to the fact that even if you wanted to update your software, you can't unless you patch it by yourself, so you know that in a month or a year from now it will be exactly the same way you left it the last time you configured it (apart from the chance the hardware fails or the security by obscurity is breached somehow).
Absolutely not. If you neglect keeping your packages up to date, it tends to get exponentially harder to upgrade them when you do need that critical bugfix.
reply