Not so fast

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