I understand the point you're making, and it actually illustrates part of the problem here.
In order to make those kinds of informed decisions about which OS to use, for example, the
people providing the options have to be honest about what they're actually providing. In the
case we have now with the Linux kernel, on paper they're saying they provide full disclosure
of security bugs, and sometimes we do see CVE and other security-related information in
changelogs (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6... just taken as a
random example) but now we find out that in reality, non-disclosure seems to be their general
policy (except for the small percentage of vulnerabilities Linus says the vendors report on).
As evidenced by some of the comments in denial on previous postings, I think some are probably
surprised now at how things really are.
So as the PaX Team is asking on LKML, there are two solutions to the problem. Either of them
will help people make better decisions regarding security: revise their written policy of
full-disclosure to reflect their real policy of non-disclosure, or change their real policy to
reflect what has been their written policy since 2005.
-Brad
Posted Jul 15, 2008 23:26 UTC (Tue) by nix (subscriber, #2304)
[Link]
I note the absence of anything in Documentation/SecurityBugs binding the
Linux kernel hackers to *anything*. All it describes is the way that bugs
sent to the *kernel security team* are managed. I see nothing that says
that security bugs described anywhere *else* need to be handled in any
particular way, or that anyone else involved with the kernel needs to pay
the document any attention at all.
(Perhaps the file needs to say more clearly that this is not a security
policy for the kernel, just a place to which people can report security
bugs if they'd rather not get the standard Linus kill-it-now approach.)
I think this has all been a giant misreading from the start.