> There are very, very few of those; way too few to be of any relevance
> for whatever you are trying to do.
first, noone has ever shown actual numbers, i.e., all this 'very few of those' is purely made up, with *nothing* whatsoever to back it up (i bet you don't answer back with actual numbers much like you ignored the rest of my questions so far, you know how well that advances your arguments ;).
second, what does it matter whether there's a lot or only a few of such fixes where the security impact is known? are they doing the same judgement call when they're fixing other kinds of bugs? like, are we to assume now that file system corruption bugs in ext* are also suppressed because "there are very very few of those"? they can't have it both ways.
third, it's none of their business what any given user is trying to do with that information. the rest of the world publishes security errata all the time with varying level of details, but the very fact of having a security bug is not usually suppressed (save for a few companies and apparently linux left in the dark ages).
> We worry there are people out there who will think that only the commits
> flagged as with security impact are important, so encouraging said
> selectiveness is a loss.
first, why is it a loss when someone backports a security fix he learns about? does it reduce his security or something?
second, and i asked this already in this very thread, who are these 'people out there' who think this way? show me a single and relevant one (i.e., not your grandma but someone's responsible for the kernel of some sizable chunk of the linux user world). i bet you can't show anyone, and you just made this excuse up to appear 'caring' yet you're achieving the exact opposite.
third, and i asked this already, but let's see if you'll avoid it: what do you think about LWN's having an entire page dedicated to security resources (errata, etc)? are they too "encouraging said selectiveness" causing a net loss? i'm sure the LWN folks are all ears to hear you out on this one.
> Furthermore, there are miscreants grepping changelogs for stuff
> like "overflow" to zero in on potential security problems.
first, show me evidence of this but then i'm pretty sure you also made this up. little hint for the future: evidence based arguments fare much better in a discussion than your imagination.
second, and i explained this too some time ago, you're assuming the existence of a person with impossible qualities. namely, you assume that a person can write an exploit based on a patch when he can read its commit message but he's unable to write said exploit based on the same patch when he cannot read the commit message. you should probably talk to some exploit writers one of these days and ask them whether they write exploits based on a few words in a commit *message* or the actual *code* being fixed. you'll be surprised, i guarantee you that ;).
third, you're assuming that exploit writers write exploits based on the commit that fixes the bug vs. the one that introduces it. what evidence is this assumption based on?
> Yes, security through obscurity, which is useful as long as it isn't for
> the long term or the only security measure.
why is security by obscurity useful when it's not for the long term? and what other security measures do the kernel devs have in place?
> What could be won with the flagging is minuscule, what would be lost is,
> in our opinion, much more than the gain.
neither of this has been established yet, but keep trying ;).
> If you want to research the security impact of bugs, knock yourself out.
> It's all out there for the taking.
so on one hand the loss (caused by disclosing security impact of fixes) is much more than the gain but on the other hand they're encouraging others to do the very same and hence cause a net loss (harm). now that's some logic there. unfortunately, they can't have it both ways.