SoylentNews is people
SoylentNews
Linux overlord Linus Torvalds has offered some very choice words about different approaches security, during a discussion about whitelisting features proposed for version 4.15 of the Linux kernel. Torvalds' ire was directed at open software aficionado and member of Google's Pixel security team Kees Cook, who he has previously accused of idiocy. Cook earned this round of shoutiness after he posted a request to "Please pull these hardened usercopy changes for v4.15-rc1."
[...] Torvalds has long been unafraid to express himself in whatever language he chooses on the kernel and has earned criticism for allowing it to become a toxic workplace. He's shrugged off those accusations with an argument that his strong language is not personal, as he is defending Linux rather than criticising individuals. On this occasion his strong language is directed at a team and Cook's approach to security, rather than directly at Cook himself. It's still a nasty lot of language to have directed at anyone.
Some 'security people are f*cking morons' says Linus Torvalds
[Reference]: [GIT PULL] usercopy whitelisting for v4.15-rc1
[Linus' Response]: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1
(Score: 0) by Anonymous Coward on Tuesday November 21 2017, @07:51AM
What I got out of it was something rather different.
"Security problems" in this context are not design problems. "Security problems" are specific, identified bugs. As such, for this type of "security problem" the proper response is in fact to address the bug, not to change fundamental kernel behavior.
Now, there can easily be "security problems" in a more broad sense, e.g. "the way the kernel currently does things is dangerous and we need to come up with a better way." These are design problems, and may warrant a more large-scale response. But those should be properly developed over time and people should be warned in case it breaks software so problems can be addressed in advance, rather than after an automatic update goes horribly awry. Addressing a bug in a patch should not result in fundamental redesign more or less on the fly, which seems to be what was done by the programmer Linus is irate with. This patch seemed to make things secure by throwing anything that might even potentially cause a violation under the bus, on the assumption that this is without question the best and only acceptable solution and anything that it disrupts is indisputably expendable. Clearly, it is not necessarily so unquestionable or indisputable after all.
A major problem is that some security people are willing to sacrifice anything and everything in the name of perceived short-term security. I think this was one of those situations.