I'm replying quickly because I'm fed up with wasting my time writing in
HTML textareas, and I still have bugs to chase down in other areas.
> 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)
Well, if what you want to see is mostly keywords, it changes things a
*lot*. As I said, building a proper commit is a tough work. Simply adding
keywords or phrases such as "maybe exploitable, costs nothing to merge
anyway" is not hard. We've been trying to work like this at least on 2.4,
noticeably with Dann Frazier from Debian who reported quite a bunch of
fixes. But in general, adding simple keywords such as "security" or "CVE"
on subject line helps a lot.
Now, about the lists' "full disclosure" after the embargo, I disagree
with your interpretation. For instance, vendor-sec charter explicitly
"...security problems first reported on vendor-sec should not be
Saying that an embargo is over and a bug is public does not mean you can
talk about everything with everybody. Most common examples are exploits.
So there's no "full disclosure" commitment, in fact it's pretty the
opposite. More like a confidentiality commitment.
> you should have left the list the moment Intel first had asked you to
> keep silent
You don't get it. Nobody asked anyone to keep silent. Nobody simply set
an end to the embargo. You may find this cowardly because noone is
responsible that way. But on another point of view, the guy may finally
come up with a usable fix and the risk of massive exploitation will have
remained lower than with a gratuitous disclosure without a workaround.
Also, it was not "intel". Just one individual, not authoritative of
Intel. That makes a difference too because threatening him will not
threaten intel, but he would simply stop working on the subject. But I
don't know why I'm explaining this, you seem well informed already.
Last, about "obfuscated commits", the suspicious examples you collected
concern Chris, Linus and Paul. Why not talk to them directly, showing
evidence of those bugs being actively used for years before their fix
and trying to convince them to be more verbose, instead of whining on
a forum they might never read about general kernel devs practises ?
Build up a collection of evidence, show them privately or publicly as
you like, and explain what issues you find there and why you think
it's bad to proceed that way. It will be quite more productive IMHO.
Once again, I'm all for giving enough information to users to justify
upgrades, while not giving enough to script kiddies. I'm for
"responsible disclosure" instead of "full disclosure". The real bad guys
are not dangerous, they have their targets and already know about the bug.
Dangerous ones are the script kiddies destructing systems to impress their
friends. That has happened a lot with the vmsplice bug. I've even read
public records of IRC channels where stupid kiddies compared their
performance on their respective friends' colocated systems. In that sense,
giving a link to a CVE and a minor adequate summary is the right thing to
do in my opinion. It can be left to the reader to push analysis further if
he wants to.
Also, keep in mind that most bug reports come from vendors' customers,
and at least for that reason you cannot divulgate too much of their
context, otherwise your security channel gets a bad reputation and you
quickly don't get bug reports anymore.
Last, I would say that most people interested in security updates are
already on security lists : distro vendors and stable maintainers. Rest
of the world either rely on their vendor or on mainline kernel. If you
feel like you'd need to get more information on the security issues,
you may ask to join those lists, and even participate in elaborating
more suitable commit messages. If you can respect a certain level of
confidentiality, you may finally get the information which seems to
be missing you too much, and finally notice that there is no such
common agreement about deliberate obfuscation.