Not so fast

> For all we know the underworld might be teeming with exploits, it
> doesn't change a thing. If you think it does change, then my point was
> not clear enough.

your point was clear in fact, and i told you it rested on this one assumption. maybe you
didn't realize it, in that case let me explain it in more detail. you said this:

> I think my scenario (find vuln, exploit it, publish and get CVE id, then
> send commit with CVE in message) is almost as dangerous without a
> published exploit.

then added:

> Et voilà! You have an unpatched vulnerability (with a published exploit > in the wild) on
millions of machines worldwide, and everyone who doesn't > update their kernels daily is
vulnerable. Is this responsible disclosure?

this comment of yours makes sense *only* if you're the first one to find and exploit a bug. if
you're not then those 'millions of machines worldwide' have been exploitable all along, well
before *you* found the bug. your entire argument falls apart since the
'end-of-the-world-if-i-disclose' situation you describe had already happened. see the point?
the only thing that changes when you, the second or later comer publishes an exploit is that
more people become able to use it - the amount of vulnerable machines does *not* change, only
the amount of actually exploited machines may. your argument is a typical fallacy coming from
advocates of various forms of 'responsible disclosure', check bugtraq and other security lists
for endless debates about it, or just the Linus quote ;).

> Talk about straw men...

well, let's see again what you said:

> I can see why giving this kind of information away in the kernel commits
> (even a CVE id) scares people. 

am i misunderstanding this or did you actually say that 'giving away even a CVE id in kernel
commits scares people'? 

> What is scary is not talking about a published CVE, but going out of
> your way to obtain one for every bug with possible security
> ramifications, instead of just fixing the damn thing.

that's not how CVE ID assignment works: you publish to a security list (vendor-sec, kernel
security, etc) and you get one assigned *automatically* by one of the guys monitoring these
lists. you don't go out of your way to get one.

> This was after complaining at length that several "security" bugs didn't
> have a CVE.

it wasn't 'security' bugs, it was security bugs. or at least one specific example i provided
that was known to be a local DoS yet nothing happened.

> Well, if there is a CVE provided with the patch then let it be
> published;

i'm glad we agree on this. now go tell that to Linus because he consistently omits the CVE
even if one's got already assigned by the time of the commit.

> but for these not-so-important issues it would only increase the risk
> for everyone.

what are these 'not-so-important issues? any example? and what risk are you talking about?

> In other cases (for crying out loud, a local DoS -- i.e. a crash) I
> don't see the point. When there are other more pressing affairs it is
> reasonable to just fix the things and forget about them.

i hope you're not a kernel contributor either. this attitude of 'fix and forget' is what puts
your users into danger because they will never know they were vulnerable. you may not care
about that fact, but some users do and fortunately you don't get to decide that for them.

> The point is that security devs have a responsibility to disclose
> whatever information is passed to them;

who are these 'security devs'? apparently not the kernel devs because you separated them next,
so i'm left wondering.

> but kernel devs are free to research it themselves and disclose their
> findings at will. Even if Linus fills his mouth with "full disclosure"
> panegyrics.

i'm sorry but that's not what Documentation/SecurityBugs says. of course you're  free to
submit a patch to correct it, then everyone will know the state of affairs (provided that what
you stated above actually reflects the consensus of kernel devs - did you even ask them before
making that comment?).

> In fact he talks about disclosing the bugs, and that is what they do,
> along with a terse evaluation.

in fact he doesn't, he says a bit more than that ('this' was about the embargo):

  The "security@kernel.org" list had lots of discussion about this when it
  was created, and quite frankly, I argued pretty strongly for total and
  full disclosure.

notice 'total and full disclosure'. it doesn't mean omitting security impact of bugs, no
matter how else you'd like to explain it away. if you're still in doubt about what full
disclosure means, i suggest that you ask the people of the mailing list of the same name.

> They were actually mentioned in spender's original message.

uhm, then i didn't get which commits you were referring to. myself, i was talking about the
ones in the previous thread and the one or two extra posted in this one.

> I assumed they were important, and yet they appear to have been
> deconstructed in this long thread.

where was, say, the double-free one deconstructed?

> So those commits he complained about are no good? We have to dig in
> additional list archives? No thanks. 

there're several commits mentioned in this and the previous thread on the same subject, go
look them up before you dismiss them. reading the rest of the posts would also not be a bad
idea before making comments ;). to get you started, find the link to the ptrace self-attach
fix and tell us its story. among others, why it didn't get a CVE.

> I hope my distro maintainers are keeping up with important issues, and
> not worrying about every "local DoS" that appears in kernel commits.
> Likewise with root-exploitable bugs.

fortunately you don't get to tell them what they should worry about. and i hope there's no
distro that thinks that way. if you know of any that has such a security bug handling policy,
please do make it known to the world at large.

> Yes: do not hide bugs and do not hide security implications. "Do not
> hide" is the relevant part here.

correct.

> It is not "research them yourself"

correct but also strawman, noone expected them to do so.

> nor "publish an exploit"

incorrect, 'full' implies disclosing such information as well, and hard-core full-disclosure
believers actually do that. but i personally don't care if kernel devs publish such code, i
care about knowing that a given commit fixes a bug with security impact at all or not.

> nor "search for the relevant CVE" 

i don't understand this one. why would they have to search for a CVE that gets created as soon
as someone submits a security issue to the security lists?

> "or get one if none exist".

it's automatic as explained above.

> If kernel devs are already fixing the bugs, full disclosure might not be
> so necessary. 

it is their declared policy for security bugs. go convince them that what they're doing 'might
not be so necessary' ;).