Stable kernel 2.6.32.8

>is that anecdotal evidence only? just asking because my anecdotal evidence is the exact opposite.

Then we will have to agree to disagree there, as it is indeed anecdotal. It is likely that the groups we have more contact with (and thus are the source of the anecdotal evidences) are different, though.

>> And certainly not just with users.
>did you mean 'users' in the sense i used it above (i.e., 'patch users', not the grandma kind)?

I did mean distro maintainers and patch users. Note that I haven't seen any evidence of skill shortcomings in the kernel maintainers of any of the larger distros, and said as much.

>> I consider "selective backporting" dangerous because I DO mean it is often being done on behalf of many others, without proper care.

>so -stable is dangerous as well since it's selective backporting.

If you trust it to have all important fixes (which is a superset of "known-to-be-security fixes" and also of "security fixes") backported in the long run? Yes, they are. However, they're the best compromise we have so far, IMO better even than getting stuck to very old distro kernels in many cases, as long as you can do your own regression testing.

>> Now, don't go making flawed "logic" assumptions.
> i didn't but maybe you misunderstood the 'your logic' reference. it wasn't about the bad implication per se, but what you used it to justify: that people are bad at logic therefore it's somehow dangerous to document security fixes in commits/announcements

I see. Well, I don't quite agree with that "justification" and I did say as much. But it is one of the main justifications that are put forward when this issue is brought up, and I can certainly see it as a valid reason to prefer to not tag security bugs as such when they are already going to be scheduled to -stable, regardless of whether I'd do it like that or not. And I am quite sure I don't know the entire picture and there are other reasons involved, on both sides.

>suddenly it's about priorities and it is very correct (and about the only practical way) to classify fixes and order them somehow given that noone has enough resources to do everything (identify/backport/test/release/support/etc) all at once

Well, when you see someone asking which fixes are the security ones, because he is only interested in backporting those post-haste, and you look at the commit logs and there are, e.g., RCU or list corruption fixes in there, it gets pretty clear that there are severe drawbacks to the mentality that only security fixes are of critical priority.

I did say I would rather see that issue addressed in other ways than silent security fixes, though.

>> As far as I know, the bias against disclosing security bugs exists due to the security theater circus.

>now this is a new one

No, it isn't. It is an old complain. It refers to two things: the amount of attention and priority that security issues (even non-major ones) are given when compared to non-security issues of similar damage potential, coupled to the importance given to gray-area metrics like "number of security bugs identified" (which is too easy to misuse) and the effects of those by the media.

I better make it clear that I am strongly against downplaying security issues, but I am also against overplaying them (because that, in practice, implies in downplaying data-corruption and system stability issues).

Note that I don't claim metrics are bad. There are metrics that are always useful and hard to misuse, such as "time to deploy fixes", and "fraction of available fixes effectively applied", and obviously, "fraction of issues with fixes available" and "serious regressions introduced by fixes". And even the metrics that are easily misused have their value.

Also note that I don't think security bugs and other classes of critical bugs are exactly the same thing, as by definition the security bugs have one extra component that makes their handling a lot more difficult: the fact that they are, by definition, something that can specifically be targeted and triggered in order to cause damage. Which brings the whole early-disclosure/full-disclosure versus responsible-disclosure (or whatever you want to call these, I apologize if I am not using the correct terms) deal.