Originally posted by bitman
View Post
Announcement
Collapse
No announcement yet.
Linux-Stable-Security Kernel Tree Announced
Collapse
X
-
As a general rule, corporations do NOT update the systems post deployment except for security fixes. From my experience, developers have learned to never update Linux post-deployment, since updating pretty much always breaks something that ultimately costs their bosses time, money, and in some cases, jobs.
Oracle is doing something developers have been begging for some time now: Creating a LTS tree SPECIFICALLY for security updates.
Comment
-
Originally posted by gamerk2 View PostAs a general rule, corporations do NOT update the systems post deployment except for security fixes. From my experience, developers have learned to never update Linux post-deployment, since updating pretty much always breaks something that ultimately costs their bosses time, money, and in some cases, jobs.
Oracle is doing something developers have been begging for some time now: Creating a LTS tree SPECIFICALLY for security updates.
The whole updates break your system problem is exactly why I build entire new filesystems from scratch in a .img which I deploy after it has been tested. I never trust linux with live in place upgrades. You're better off building a new one, testing in house, and then deploying over the network.Last edited by duby229; 12 April 2016, 08:34 AM.
Comment
-
Originally posted by tpruzina View PostBetter question yet, how do you differentiate between security fixes and "normal fixes".
I remember there was an "off by one" [bit] bug that people considered unexploitable right until somebody came up with really clever exploit that played around with page allocation untill it abused that arbitrary bitflip to cause permission change on page value.
Also, security fixes are never marked as security bugs in commit logs as a policy (at least hackers have to look at bugs to figure out exploits instead of grepping git log).
- Every bug is a serious bug that needs handling, no matter what.
(You have no idea how someone will find a creative way to abuse a bug for exploiting or plain simply borking your server),
Originally posted by chithanh View PostBecause bugfixes can introduce regressions. The trade-off to have a secure system might be worth it. But if you are unaffected by the bug that is being fixed, then running that risk is possibly not a good idea.
basically:
- either the bugfix is in a codepath that NEVER gets executed on your system (i.e.: it's inside a driver for a different piece of hardware, that you therefore don't load) in which case you don't give a damn about the bugfix.
- or it's a bug which you do run. then you'd better stop complaining and do your due dilligence to test against regressions and deploying, before something nasty happens because of this bug.
(be it the system barfing on corrupted data instead of degrading nicely. Or be it an intruder deciding to have some lulz at your expense).
Originally posted by duby229 View PostThe whole updates break your system problem is exactly why I build entire new filesystems from scratch in a .img which I deploy after it has been tested. I never trust linux with live in place upgrades. You're better off building a new one, testing in house, and then deploying over the network.
- Likes 1
Comment
Comment