> 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.
i see you haven't seen my other posts in the thread, so i'll ask you as well: how do you know
you're the *first* one to find and exploit a given bug? answer: you don't. from that point on
your entire argument falls apart because that was the one assumption it rested on (if you're
not the first one then you're not saving anyone but yourself, from embarrasment). not to
mention that you're talking about something we never did: nowhere did we say that we want
exploit code in commits for example. as for how putting even as little info as a CVE in
commits scares people, go tell that to the -stable guys because they're trying their best at
doing exactly that. will you crucify them because they're spreading terror among the populace,
to paraphrase you?
> I don't think it was a misrepresentation, but whatever.
you don't? did you even read how you introduced that scenario? here it is for you again:
> you have to realize the consequences of the way advocated by spender and
now you tell me how this is not putting words into our mouth. where did we say anything
remotely resembling that? unless you can point to a post we made, you put up a strawman and
attacked it as if it was relevant to the discussion (it wasn't, for other reasons as well, see
my comments on disclosure policy vs. consistency/honesty).
> If it is vendor-sec then Documentation/SecurityBugs does not apply.
other rules still do and they don't call for hiding security impact information. but you're
not a member of either list therefore you couldn't know.
> When it is the kernel security list it applies, but this policy document
> doesn't say what you seem to think it says.
it says full disclosure. the initial participants knew full well what that means. to show that
the whole concept isn't exactly foreign to them, here's a few choice Linus quotes:
I really _despise_ people who think security is an issue of hiding bugs.
If they then try to make themselves look good ("no zero-day exploit, we
fixed it immediately"), they're worse than low.
The only thing that seems to work for security is public shaming.
and another addressed to vendor-sec:
I don't care what the hell people do on vendor-sec, and you can do your
"responsible" mental masturbation all you want, but as far as I'm
concerned, the _only_ responsibility I have is to fight that tendency to
hide bugs as much as I can.
you tell me if he was advocating withholding security impact info or not. yet we showed how he
did exactly that himself.
> It clearly states that kernel security officers will disclose what they > are told as they
no, it doesn't say that. the only wiggle factor it mentions is about setting the disclosure
*date*, not its amount.
> and anyone reporting the bug cannot rely on secrecy upon their part.
no secrecy = full disclosure. thanks for confirming it.
> From what we have seen bugs are disclosed, just not the way you like.
you either don't read or understand what i'm saying. you're once again talking about
disclosure policy, not consistency. i will say it again then, in the hope you get it: i do
*not* care about the chosen disclosure policy per se, i *do* care about holding it up. so when
the current Documentation/SecurityBugs says 'full disclosure', i expect that. if it said
something else, i'd expect that then. clear enough now?
> You are getting all worked up because commit messages do not reflect the
> kind of information you would like to be there, and that is fine, but it
> does not follow from the document that it should be there. "Full
> disclosure" is not "crying wolf".
you don't know what full disclosure is about, that's clear already. please, if you want to
save further embarrasment for yourself, go read up on the subject before making further silly
comments like the above. hint: disclosing security impact information is not "crying wolf".
> In this thread we have seen a bug which cannot be exploited
those commits were mentioned in passing only because they looked suspicious, not because there
was any coverup related to them. the subject of this discussion is commits where we did say
coverup and you tell us what happened there (go ask for the mailing list archives, the answer
> I say that security professionals who rely upon kernel commits to
> perform security assessments are crazy.
and i say that you're not a security professional. the ultimate goal/job of said professionals
is helping the risk management process and any useful piece of information is valuable input
to that. if a given piece of information turns out to be false (because, say, someone decides
to not hold up to his publicly declared full disclosure policy), then there can be
misjudgement and bad decisions affecting innocent people down the ladder. so in case you still
didn't get it: kernel commits are one source of information and it's of great help (read: time
and human resource saver) when one can simply grep the changelogs for keywords. and one would
rely on that because he believes that commits are actually part of the full disclosure
process. when they aren't, one can miss things unless he invests in a whole lot more resources
to figure that out himself (don't only think of companies but also other distro maintainers
> Where does it say that "kernel commits will contain all available
> information for security professionals"?
We prefer to fully disclose the bug as soon as possible.
for actual security professionals (unlike you, that is), 'fully disclose' has a specific
meaning. the kernel devs know it as well. go ask *them* if you're in doubt. so when a commit
and the bug its fixing doesn't get a CVE, we have a problem (i gave an example of that, read