User: Password:
Subscribe / Log in / New account's road to recovery's road to recovery

Posted Oct 10, 2011 8:38 UTC (Mon) by jrn (subscriber, #64214)
In reply to:'s road to recovery by PaXTeam
Parent article:'s road to recovery

> care to list a few projects (preferably something as 'important' as linux) that actively suppress CVE info as linux developers do?

"git log --grep=CVE" does not show me signs of active suppression of CVE info. Are you sure you didn't misunderstand Linus?


(Log in to post comments)'s road to recovery

Posted Oct 10, 2011 9:03 UTC (Mon) by PaXTeam (guest, #24616) [Link]

compare the list of kernel CVEs at ( with the git log.'s road to recovery

Posted Oct 10, 2011 9:31 UTC (Mon) by jrn (subscriber, #64214) [Link]

Which translates into active suppression how, exactly?

Some fixes are even made before a CVE is allocated. Since commit messages are not changed after the fact, the git log is not a good place to keep a canonical mapping for CVEs to commit names. Good thing the CVE database exists, huh?'s road to recovery

Posted Oct 10, 2011 13:02 UTC (Mon) by PaXTeam (guest, #24616) [Link]

you were asking for 'signs of active suppression of CVE info'. lack of CVE numbers in commit messages is 'signs' in my book. whether the actual reason was active suppression or something else is something you'll have to research. actually, you can do much better to prove your point: show me the commits that fix all the CVEs not explicitly mentioned in the commit logs. every one of them. if it takes you more than a few seconds then you lost (my bet is on days assuming you even have the knowledge to read and understand kernel code and security bugs). do you understand now why it's important to not cover up security bugs?'s road to recovery

Posted Oct 10, 2011 13:48 UTC (Mon) by vonbrand (guest, #4458) [Link]

Oh, come on. In the development branch of the kernel somebody notices a glitch and fixes it. Some weeks or months later, somebody running a production kernel finds a security problem, which is dutifully assigned a CVE and the whole circus. The patch is backported from the development branch (or redelevoped independently). Or even somebody fixes a bug, somebody else looking over the commits gets intrigued, develops a PoC exploit, a CVE gets assigned. Or a bug is discovered and fixed, its security impact is assesed and reported, a CVE is issued. In all these scenarios the CVE asignment comes after the patch is integrated. Small wonder the CVE isn't mentioned in the changelog.

Yet again, if you want to decorate each commit with CVE numbers, PoC exploits, detailed security assesments, knock yourself out in your own git tree. For me it is enough that the bug got fixed, and move on. Sure, security fixes should be backported. You know what, that is what the -stable trees are for...'s road to recovery

Posted Oct 10, 2011 14:43 UTC (Mon) by PaXTeam (guest, #24616) [Link]

you're talking about possible lifetimes of security bugs, i specifically talked about the ones whose security impact is known *before* any fix gets committed. the problem with such fixes is that their commit message tends to not mention that little fact. and no, such information doesn't belong to any other tree first than the one where said fix is committed. do you understand the problem now?

> For me it is enough that the bug got fixed, and move on.

how do you know when a security bug gets fixed when such information is covered up? have you got some psychic abilities or other channels that mere mortals are not privy to?

> Sure, security fixes should be backported.

yes, if you know which commits fix security issues. you too can point out every single commit that has a CVE but isn't mentioned in the git commit log. you see, if you can't find them, then how could others?

> You know what, that is what the -stable trees are for...

wait, are you saying that the -stable trees contain all the CVEs that are missing in the Linus tree (since the importance of the backported commits must be known by then)? can you back it up with actual numbers? ;)

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