"Stable" kernel 2.6.25.7 released

> 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
> PaXTeam

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
see fit,

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
is there).

> 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
for example).

> Where does it say that "kernel commits will contain all available
> information for security professionals"? 

here:

  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
the thread).

> So very many people are failing to get the point: might it be that
> you're not expressing yourself very well?

not many, only first time posters who simply didn't read what i said before.

> Either that or you're saying this to divert attention from questions you
> can't answer.

which questions would they be (and you probably meant "don't want to", as you can't seriously
expect me to answer questions that i, well, "can't" ;)? if i missed anything, feel free to
point them out to me.

Some get it, but some do not (the ones trying to misinterpret all the provided evidence to
support their view).  Unfortunately for them, the way things are is often not as how we
imagine or would like them to be.

If even Willy is saying that Linus intentionally omits security information at times in his
commits, which he is fully aware of at the time of the commit, why are you still quibbling
with us?  I was surprised myself Willy was so honest about this (I appreciate it), and it
meshes with the private evidence I have.

In general, from the evidence I have, the people in charge of handling security put forth a
lot of effort and in most cases handle things properly.  This is especially true of bugs that
are submitted to them from the outside, where security-relevance is either explicitly
mentioned or suggested.

But in some cases (the specific examples already provided and others I'm currently compiling),
things aren't handled properly.  It seems so far that these involve bugs that haven't been
labeled as security-relevant by individuals/companies in the public realm.  Many of these bugs
seem to be DoS-related.  On their private lists will exist PoC code to trigger them, so their
security-relevance is well known to the members of the private lists, and yet often it's these
that get handled improperly.

Like we had been arguing, this isn't a conspiracy.  They don't coordinate on the lists on how
to cover up the security bugs for the day.  But there does seem to be some adherence among
some to an "unwritten rule", that if they aren't being publicly held accountable for
something, the rules can be relaxed.  The problem is they end up hurting themselves (and all
of us) this way, since when things aren't mentioned properly publicly through the changelogs,
it often never gets proper classification (see the SELinux remote DoS at the bottom of the
page).

As to why you continue to argue, this might help explain the uncomfortableness you're feeling:
http://en.wikipedia.org/wiki/Cognitive_dissonance

-Brad