On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote: > On Fri, 9 Aug 2013 06:38:56 -0400 > Rich Freeman <ri...@gentoo.org> wrote: > > > My sense is that Greg is using the term security bugs to refer to > > implementation errors that could be exploited to obtain unintended > > access to a system. Using this definition, any bug could be a > > security bug, and figuring this out is about as easy as figuring out > > whether a particular move is a good or bad one in chess. > > That's indeed not what I understood; Greg, was this your though?
Yes, that's close to the issue. Any bug could be classified as a "security" bug if you wish to do so, so there's no need to call out some fixes and not others, as odds are, you will miss some, and give people the wrong impression they are safe when they are really not. > > I don't follow the kernel closely, but my guess is that they stay > > well-ahead of CVE most of the time. I'd certainly say that any > > project should clearly document which releases incorporate fixes to > > CVEs - perhaps the kernel already does this. > > Currently I don't see this; so, my assumption was that it does not > currently happen, as far as I have seen this appears to happen on an > individual basis, but I assume not everyone does report to CVE. > > Reporting to CVE is much more work than it takes to tag a commit; so, > as you can see tagging here might be a benefit to lift the work to > other people that have more time for reporting it as a CVE, etc... The kernel usually has things fixed it in long before a CVE is asked for. So there's no way to go back in time and add CVEs to commits. thanks, greg k-h
