The core issue

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

it wasn't me who decided that the kernel security bug disclosure policy should be that of full
disclosure. you're free to change it if you can't live up to it for whatever reason.
alternatively, you can make the archives public after the embargo so that people can get the
whole picture. the current situation is not good as it hurts users.

> But in general, adding simple keywords such as "security" or "CVE"
> on subject line helps a lot.

indeed and this is what's missing among others in 2.6 commits (which is what we've been
complaining about, not 2.4).

> Now, about the lists' "full disclosure" after the embargo, I disagree
> with your interpretation.

'full disclosure' is not subject to interpretation. if you withhold information, then it's not
'full', period. check the full-disclosure mailing list if you don't believe me (it's full of
exploit code, there's no embargo observed, etc). you're free to call yours something else and
then everyone will know what to expect.

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

i know all that Willy, that's why i said that vendor-sec was known *not* to practice full
disclosure. the kernel security list however, as of now, has a declared full disclosure
policy.

> You don't get it. Nobody asked anyone to keep silent.

not true. you stated yourself the vendor-sec list rules that you don't talk about issues in
public. this one was no different, the list rules still apply. if the list had been public, do
you think Intel would have told you about this bug?

> Nobody simply set an end to the embargo.

not true, there was an embargo set but it came and went, nothing happened except the patch got
into at least one distro afterwards, that effectively made it public and thus ended 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

you know now that it's not possible because the bug can only be fixed in hw properly.

> and the risk of massive exploitation will have remained lower than with a
> gratuitous disclosure without a workaround.

so you're saying that the world would have been better off if the FDIV and F00F bugs had never
become public? are you seriously justifying this new Intel coverup?

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

someone posting from @intel.com cannot state on his own behalf that Intel would not provide
the code sequences that trigger the bug. and holding Intel accountable is not threatening
them, except their bottom line if angry customers hold them, well, accountable for their bad
decisions.

> But I don't know why I'm explaining this, you seem well informed already.

the world isn't Willy, that's the problem. and when Intel does finally fix the bug in a future
chip, what will happen to the people running with the old ones? will you/they keep them
ignorant about their buggy chips forever?

> Last, about "obfuscated commits", the suspicious examples you collected
> concern Chris, Linus and Paul. Why not talk to them directly,

and tell them what they already know? i don't see the point...

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

we're not whining, we're telling the world that things are not exactly as one would naively
believe. although i don't expect kernel devs to read everything on lwn, i know that many of
them read this one and they got the message. question now is what they'll do with it, in
particular, will they live up to full disclosure, or will they keep downplaying security
issues.

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

the evidence is in secret mailings lists. will you make the archives public? this is the point
we made: noone is accountable because everything is done in secret. how can *we* change that?

> I'm for "responsible disclosure" instead of "full disclosure".

i posted somewhere below what Linus had to say about 'responsible disclosure' (look for
'mental masturbation'). you're in wild disagreement, to say the least.

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

noone asked for that (although the kernel devs' commitment to full disclosure would imply
disclosing even such information, personally i don't care or think it's interesting or
necessary).

> Last, I would say that most people interested in security updates are
> already on security lists : distro vendors and stable maintainers.

not true at all. one must meet some definition of 'elite' to get on these lists. you know full
well how individual researchers are *not* welcome on vendor-sec for example.

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

i may ask and i will get rejected. thanks, but no, thanks.

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

i don't need to be on any list to notice when something's covered up. FWIW, i'm not the first
one to have made such an observation: http://marc.info/?l=bugtraq&m=115255401805462 - you know
who he is, right?