On the security of our processes and infrastructure
Posted Sep 17, 2011 4:28 UTC (Sat) by malor (subscriber, #2973)
[Link]
Which means you inevitably must also accept a bunch of new features that haven't been completely thought out or tested, resulting in yet more patches resulting in yet more untested features resulting in yet more patches. It's a never-ending stream of 'which insecurity do I have this week?'
At this point, if I had data that would threaten my livelihood or life if it leaked, I would never, never not EVER put it on a Linux box.
On the security of our processes and infrastructure
Posted Sep 17, 2011 20:00 UTC (Sat) by jrn (subscriber, #64214)
[Link]
> Which means you inevitably must also accept a bunch of new features
Have you looked at a linux-stable (i.e., 3.x.y) kernel recently?
On the security of our processes and infrastructure
Posted Sep 19, 2011 12:31 UTC (Mon) by mpr22 (subscriber, #60784)
[Link]
I certainly know that at this point, if I were the maintainer of an OS kernel I would flag all fixes to the kernel as security fixes, simply because (a) selectively flagging fixes is subject to human error (b) there are too many people out there who can't be trusted to know the difference between "A implies B" and "not-A implies not-B". (In this case, A is "the fix is flagged as a security fix" and B is "omitting the fix has negative implications for the security of the system".)
Out of interest, what OS would you trust to keep such information safe? (For my part, I think the right solution there is to keep the information strongly encrypted, and never let the keys reside - even in volatile storage - on a network-connected device.)