I'm not missing the point, really. I *agree* with the primary point, that
security holes should be described better: I just don't think that it's a
sign of malice (or intent at all) that they aren't described better, and I
can't see any practical way once the changelog is written to get them
described better, and for Linus and upstreams to scan every change for
signs of this sort of thing and rewrite their changelogs does not scale
(not to mention that that sort of changelog rewrite in effect means a
rebase, and Linus rebasing his tree a lot would be... problematic for
everyone pulling from him).
The thing that has to be done, of course, is to educate people to think
securitywise, so that they ask the same questions Brad asks: `how might
this be abused?' for starters. But most people, even most kernel hackers,
don't think like that (and if programmers did then a lot of security holes
wouldn't appear in the first place).
It's just that there is no quick fix. If this was some conspiracy on the
part of a few individuals, as some above suggest, then fixing it would be
easy. It's not.