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 --
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Rafael J. Wysocki | Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4d... |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
