Stable kernel 2.6.32.8

Yes. I happen to think that is a bad thing, and I said as much, so I wonder why the heck you brought that up.

>So you've established that some of these people doing backporting are "unprepared" -- do you think they know that refcount overflows are exploitable? ...

Many of the regular kernel developers won't know that (or recall that fact), so I wouldn't expect most of the distro maintainers to, either. That would be the reason why the distros are supposed to have some very security-minded people in their kernel teams.

>In other words, how is the current policy of deliberate obfuscation *better* than mentioning that one found a security bug when that was known at the time to be the case?

I believe the point is that it forces *every* -stable patch to be backported which is a fine goal by itself, at least IMHO.

That won't help with the stuff that never goes to -stable, but those are very likely to be bug fixes where the developer doing the fixing doesn't even realize he fixed a security hole, coupled to said developer either having a weak "let's keep -stable fixed" commitment, or feeling like the fix is too invasive for -stable.

That, of course, means that the case where someone would see a security fix targeted at mainline, realize that older kernels are vulnerable but the maintainer didn't notice that (maybe they're vulnerable in a slightly different way), and alert someone that -stable needs fixing becomes much harder to happen.

> The vendors and others that have to do backporting aren't happy with this policy

Well, I am still waiting for people from the RedHat, SuSE and Debian/Ubuntu kernel security teams to say that.

> What's being done to make their job easier

The -stable tree.

> Is it responsible to stick one's head in the sand and claim no responsibility for the problem?

That's not what I see happening.

However, there *is* something I do see happening. People with the skill to really help (e.g. you), aren't doing anything hard to change the status-quo, even if it bothers them enough to "not be happy with this policy".

Why can't we have an independent report from you or other kernel security specialists, published regularly, with information on the security implications of every patch hitting -stable (-mainline would be too much)? You know you can get early access to all those patches, don't you? Anyone can, they just need to ask to be in the review team. And I am pretty sure you know your report WOULD be read, and acted upon.

Why can't we see a series of articles from you or other kernel security specialist here in LWN, teaching the kernel developers about all the security issues they should know to identify at a glance, with examples of exploits for each class of pattern to get the point home?

It is completely fair if you don't do that because you have better things to do with your time, or because it doesn't suit your (or your employer's) agenda. But it is also completely fair if the kernel developers don't do what you want because they believe their way is better (or because it doesn't suit their, or their employer's agendas, whatever).

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