The core issue

> Well, I know that Linus does not like to give too much information in
> the commits because he believes it will help the bad guys, reason why
> he does not add the methods to reproduce the problems nor the CVE when
> he does the commits himself.

that's obviously utter crap. the bad guys are smarter than him or any kernel contributor.
they'll spot the bugs *before* they do. they'll also spot the bugs in the commits regardless
of what the commit says. does anyone remember the collective bruhaha in the security world
when CVE-2006-2451 became public? IIRC, that was a full year after the original commit and
also a full year after at least two working private exploits for it. on a sidenote, IIRC, that
bug still isn't fixed properly, as soon as a sysadmin enables the suid coredump feature, it's
exploitable again.

but actually i don't care about his opinion. what i do care about is that his published
commitment to full disclosure matches what he actually does and that's where the problem is.
you see, withholding security impact information doesn't full disclosure make. you guys can't
have it both ways because the people relying on you expect you to hold up to that commitment
you made in Documentation/SecurityBugs and if you violate that promise, people will make wrong
decisions and innocent people may suffer as a result. so if you want to stick to withholding
security impact info from commits, say so and the world will adjust. but let me guess, that'd
also be bad PR and you don't like that part.

> You have to keep in mind that most often, a commit is a summary of 10-20
> mail exchanges with reproducers, tests and results. You cannot put all
> that in a commit.

that's a strawman Willy, noone asked for it. what we did ask for was inclusion of known
security impact details. it doesn't overflow anyone's mailbox or git repo if you include a
*single sentence* saying that this is a potentially exploitable buffer overflow or NULL deref
or whatever. people can grep for the keywords and make further judgements based on whatever
extra research they deem necessary (including asking the committer for more details). once
again, this info doesn't help the bad guys because they'll spot this regardless of how obscure
the commit message is.

> What I'm really sicked about is the accusations of "general agreement to
> deliberately hide security informations from commits". That's false IMHO,
> really. And in fact, examples given by Brad were on public lists, so that
> does not make any sense.

when you publicly commit to full disclosure, yet, by your own admission now, you don't
actually practice it, then what do you call that? i call that general (silent or otherwise)
agreement of all participants. after all, participation in handling the kernel security bugs
is voluntary, noone forces you or anyone else to do it against his better judgement. therefore
if you play ball there, you de facto accept the not-exactly-full-disclosure policy (you later
admit that regarding vendor-sec, except everyone knows that vendor-sec does not practice
full-disclosure so people don't build that expectation into their decision making processes).
do you understand the problem better now?

> What we agree about is not to divulgate information when joining the list.

that's not the whole truth. what you also agree to is full disclosure after the embargo. go
read Documentation/SecurityBugs if you don't believe me. do you admit that you don't actually
practice it? if you do, we can take the discussion further and figure out whether you want to
actually update Documentation/SecurityBugs or really adopt full-disclosure. if you don't,
we'll keep on exposing the fallacy because we have no other way to affect you and at the same
time help the world by letting them know that their security risk analysis processes are based
on false promises.

> But I have never seen anything there such as "hey shhht! don't tell
> anybody, let's fix it silently".

i quoted Paul Mackerras a few times now. what do you have to say about that quote? why would
someone practicing full disclosure even *ask* that question and then actually withhold the
more important security impact?

> [stuff about the itanium hw bug]
> If a fix cannot be developped, game over!

not true. did the FDIV or F00F bugs mean game over? i don't think so. last time i checked, the
world hadn't stopped back then. what did happen was a huge PR disaster for Intel (in part
because of the same coverup attempt they're doing again). and history is repeating itself,
except this time you guys are actively party to the coverup. you should all be ashamed and the
conscientous of you should have left the list the moment Intel first had asked you to keep
silent because they didn't feel like fixing the chips. something tells me that there's another
PR disaster in the making.

> Believe it or not, it is already the hardest part of my work, determining
> the relevant information.

this is another strawman Willy, as this should not be your work at all and noone asked for it.
what we do ask for is that if you guys learn about security impact information during the
course of bug examination, then you *do* include those details in the commit. noone is
expecting anyone to spend time on thorough bug impact analysis, most of you are not even
qualified for that, it's really hard and time consuming work (just look at this very thread
and see how i missed stuff ;). but, say, if you see a kernel stack overflow then you say so
and don't try to be creative by calling it 'copying overly long strings' and similar crap. of
course there's always the alternative of publicly admitting that you do not in fact want to
practice full disclosure. it won't look cool in PR events but you can at least sleep with
clear conscience.

> And please, do not say "obfuscate" when speaking about commit logs,
> it's more like "summarize", even if extreme summarization may lead to
> obfuscation.

sorry, but i have no better words when i see something like
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
do you really call that 'summary'? i hope not.

> Could you elaborate please ? This fix is in Linus tree, and I don't see
> Chris in the sign chain. Did he report it first ? Also, I'm sorry, but
> I fail to see the security implications of this patch, eventhough seeing
> "ptrace_attach" catches my attention.

don't you think there's a reason you fail to see the security impact and that i cited this
particular commit? go ask Chris about the history of it, you'll be surprised. in short, this
*is* a local DoS, the kernel devs were provided proof-of-concept code *yet* Linus deliberately
did not include any of that information. then Chris deliberately omitted it from the -stable
commit as well. wild accusations? or the unbelievable truth? it's yours to find out and you
even know how.

> From what I have seen, this was finally judged as a non-issue since other
> checks are in place, which probably explains why you don't have it in
> stable. It is very often that fixes for supposedly real vulnerabilities
> finally end in mostly code cleanups.

it would have been nice to mention this in the commit as well.

> What amazes me, to be honnest, is the ability you have to spot patches in
> mainline that take a lot of time to other people. I'd love to know how
> you proceed, it would save me a lot of time.

uhm, there's nothing magical in this. i sometimes check the kernel shortlog looking for
potential conflicts with PaX and obviously my eyes catch sometimes other 'interesting' looking
commits which i then go and look at in detail.

> Or maybe you spend whole days at this, in which case all users would
> benefit from your findings.

not at all, as i said somewhere below, i do it on my free time, always have in fact. and these
days, i'm trying to actually spend my time on other things. but as long as i can't give PaX
away to a new crew, i'll have to have a look every now and then.

> Why don't you post on LKML, to -stable or even on security lists links
> to the patches you consider suspicious security-wise ?

what would that change? more flames, more excuses for why it's not a good idea to support the
bad guys, etc. and in the end, as i said above, that's not what i care about but rather the
consistency between the promise made to the public and the actual actions. i can't fix any of
that because it's not of my making.

> Even assuming everyone's honnest in the chain, and the other people
> considered the bug inoffensive when you think the contrary, you could
> educate people about your methods of discovering this.

that's a whole separate issue of figuring out that a bug has a security impact after the
commit. i'm afraid such research requires a full staff, and i'm not in the position to fund
anything like that. heck, i'm happy when i make ends meet here ;).