Not logged in
Log in now
Create an account
Subscribe to LWN
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
LWN.net Weekly Edition for June 6, 2013
I never said that CVE is a waste of effort, but it isn't part of each program's change log either.
Kernel.org's road to recovery
Posted Oct 10, 2011 8:19 UTC (Mon) by PaXTeam (subscriber, #24616)
you declared that research into the security impact of fixes is 'Pure noise, a complete waste of effort' due to false negatives and positives. you can't have this both ways, i'm afraid ;).
> but it isn't part of each program's change log either.
care to list a few projects (preferably something as 'important' as linux) that actively suppress CVE info as linux developers do?
Posted Oct 10, 2011 8:38 UTC (Mon) by jrn (subscriber, #64214)
"git log --grep=CVE" does not show me signs of active suppression of CVE info. Are you sure you didn't misunderstand Linus?
Posted Oct 10, 2011 9:03 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Oct 10, 2011 9:31 UTC (Mon) by jrn (subscriber, #64214)
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?
Posted Oct 10, 2011 13:02 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Oct 10, 2011 13:48 UTC (Mon) by vonbrand (subscriber, #4458)
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...
Posted Oct 10, 2011 14:43 UTC (Mon) by PaXTeam (subscriber, #24616)
> 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? ;)
Posted Oct 10, 2011 13:34 UTC (Mon) by vonbrand (subscriber, #4458)
I did not say that research into security impact of fixes is useless, I contend that the first impression by the one doing the patch is probably useless. Quite a different statement.
Posted Oct 10, 2011 14:31 UTC (Mon) by PaXTeam (subscriber, #24616)
> Any such assesment they do will miss an order of magnitude more
> exploitable flaws than the ones flagged, and flag many that are
> completely irrelevant. Pure noise, a complete waste of effort.
i don't see 'first impression' in there, but i do see 'assessment' which in my book is much closer to research than what you now claim you meant. but let it be ;), the main thing is that you now admitted that there is such a thing as security bugs (you're one step ahead of the kernel devs) and their research is not useless, contrary to what Linus/Ingo/etc claimed over the years. the next step you'll have to make is that doing the research is not enough, it has to be published to be of value and then we're on the same page and can ask the kernel devs together to not suppress such research. i'm so rooting for you!
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds