LWN.net Logo

Kernel security, year to date

Kernel security, year to date

Posted Sep 10, 2008 20:26 UTC (Wed) by PaXTeam (subscriber, #24616)
In reply to: Kernel security, year to date by dlang
Parent article: Kernel security, year to date

> if you don't want to only apply security fixes to get a secure system,

what do non-security fixes have to do with the security of the system?

> why do you need the big red flag that a patch is a security fix?

why? it was in my post, read it again ;). keyword: priority. and if the security bug isn't marked as any kind of important fix whatsoever (as it is the modus operandi apparently) then how is anyone supposed to figure out that it needs to be backported? besides, what is this 'big red flag'? do you only think in extremes?

> if you are applying all bugfixes then you will get the security fixes
> along with everything else.

you're again thinking in black&white mode. what makes you think that people want all or nothing? what if sometimes one needs to prioritize and does risk evaluation before deciding on backporting and/or applying a fix?

> as for the reason to not call it out, to give the good guys a chance to
> apply fixes before the bad guys are writing exploit code.

this 'argument' has been thorougly debunked back in July. the short story is that guys capable of writing exploit code do not need such marks in commit messages because they will figure it out themselves, sometimes as soon as the commit containing the security bug goes in, way before any fix can possibly reach the good guys.

it's also funny that you're assuming that by not marking a commit as a security fix, the good guys will somehow be better off in identifying it as such.


(Log in to post comments)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds