On Fri, 9 Aug 2013 06:38:56 -0400 Rich Freeman 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? > I think Tom is using the term security bug to refer to a bug that has > a published exploit against it (ie a CVE/etc). Using this definition > it is clear whether a particular bug is a security bug - it is either > in the database or it isn't. This is indeed what I assumed Greg meant; so, thanks for clarifying. > 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... > Since most bugs get fixed before anybody bothers to file a CVE, I'm > not sure how much that actually matters in practice. It is dangerous to assume something you fix isn't known yet. As I said before, it buys the people that do know time; whether or not a CVE or any other form of public or less public documentation on it exists. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D