Linux-Stable-Security Kernel Tree Announced

[chithanh]

So whats the point to discard bugfixes if they are not security-related?

Because 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.

[gamerk2]

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.

[duby229]

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.

I don't think it has anything to do with developers. Oracle has it's own customers and I'm positive this is only being done because they have been able to determine that their own customers aren't updating their shit.

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.

[DrYak]

Better 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).

Yup this has always been Linus' perspective on Linux bugfixing:
- 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),

Because 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.

if you *think* you are unaffected by the bug that is fixed, then running that risk is possibly not a good idea... right until the moment when a creative mind finds fun (for them and bad for your) things to do with it.

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).

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.

That would be best practices... which of course you're (saddly) the only existing person that follows them.