> "Candid" doesn't mean hidden
i never said it did. what Paul was asking the kernel devs was about how honest he should be in
the commit. the mind boggles at that very moment as this was on a list whose declared
disclosure policy is full-disclosure (see Documentation/SecurityBugs if in doubt). then what
do we get in the commit? complete omission of the more serious security impact (arbitrary
kernel memory read). you call that whatever you want, i call it dishonesty. it's not terrible
per se, it's just it's in direct contradiction to what was communicated to the public before
and what this supposedly superiour development model is so proud of among others. as they say,
you can't have it both ways.
also, this one at least got a CVE that, as far as i know, you can't say about that ptrace bug
i posted somewhere above (not even the corresponding -stable commit mentions anything at least
yet the -stable guys were fully aware of its impact - this by the way directly contradicts
Chris Wright's claim in http://marc.info/?l=linux-kernel&m=121312896523183&... ).
> I explained that commit messages aren't specifically called out as a medium for security
says who? 'tialaramex' or is it the agreed-upon (read: documented for the public) commit
policy of kernel developers?
as for what percentage of kernel bugs have a security impact (or did you mean something other
than 'kernel code' by 'privileged code'?), i stand by my claim that it's not *most* of them (i
never said 'only a handful' either, nice strawman though). this is based on my personal
PS: congratulations on finding yet another silently fixed potential security bug.