On Tue, 15 Jul 2008, pageexec@freemail.hu wrote:The issue is that I think it's then _misleading_ to mark that kind of commit specially, when I actually believe that it's in the minority. If people think that they are safer for only applying (or upgrading to) certain patches that are marked as being security-specific, they are missing all the ones that weren't marked as such. Making them even _believe_ that the magic security marking is meaningful is simply a lie. It's not going to be. So why would I add some marking that I most emphatically do not believe in myself, and think is just mostly security theater? I generally do not remove peoples changelog entries, although I _will_ do even that if I think it's just too much of an actual exploit description (of course - the patch itself can make the exploit fairly clear). So you'll find CVE entries etc in the logs if you look. But I do hope that anybody who looks for them is _aware_ that it's just a small minority of possible problems. Don't get me wrong - I'm not saying that security bugs are _common_, but especially some local DoS thing for a specific driver or filesystem or whatever can be a big security problem for _somebody_. Linus --
| Scott Preece | Re: Linux Foundation Technical Advisory Board Elections |
| Luis R. Rodriguez | Re: [Announce] Linux-tiny project revival |
| Andrew Morton | 2.6.23-rc1-mm2 |
| Dave Hansen | [PATCH 02/24] rearrange may_open() to be r/o friendly |
git: | |
| David Miller | [GIT]: Networking |
| David Miller | Re: [BUG] New Kernel Bugs |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
