Kernel.org's road to recovery

Sometimes it seems as though the groups - socially - are more alike than different, just resent the resemblance.

it was 'bad faith' and i think you've got enough proof now (straight from the horses's mouth even) that i was right ;). as a sidenote, calling someone a looney is "*really likely* to make people trust you and want to work with you". oh the irony ;).

> This is why PaXTeam's excellent technical nous goes largely wasted into
> out-of-tree stuff that is relatively little used[1]:

being out-of-tree is not a waste, it's called a fork and is actively encouraged by kernel developers (i'm sure you can google some Linus quotes to that effect yourself). second, PaX is more like a research project, not a product, so it's natural that its userbase is restricted. nevertheless, the ideas pioneered there over the years have found their way into every major OS these days (linux, BSDs, iOS (both kinds of them), OS X, Windows, etc). i wish every good thing in the world was this 'wasted' ;).

> when he tries to interact with other people, the moment any criticism of
> any kind is levelled -- which takes about six seconds on a list as
> hardboiled as the kernel list -- out come the vituperative personal
> attacks, conspiracy theories, and imputations of malice -- and of course
> he is never wrong either, no matter what evidence is presented

that was quite a mouthful, but let me try to make some sense of it. first, some kind of proof would be useful in general when you throw out accusations (the irony is that you asked for the same in the past, yet are refusing to do the exact same thing when it's your turn ;). second, you should probably be reading more lkml to know the context better and understand the social interactions there. third, what evidence are you talking about? last i checked, i had a few dozen unanswered questions left, both on lkml and here, and i'm still waiting patiently for the 'evidence' ;).

> I expect further personal attacks in response to this comment [...]

so you go out of your way to attack me personally and at the same time make also snide remarks at kernel developers. and then you run and cry 'but pretty please do not come after me'. IOW, you've just proven yourself to be a troll (not that i had any doubts before ;).

PS: your knowledge of the linux ecosystem is kinda outdated. Fedora et al. are 'irrelevant'. what matters today is android, by virtue of having an install base of orders of magnitude bigger than even Ubuntu. the rest is 'also run' (no disrespect meant, but nix's playing the numbers game here and the numbers are like this. i personally don't care which particular linux flavour ends up using PaX or other ideas, the important thing is that they're available for those who need them).

Currently, they - by their own admission - choose not to reveal such knowledge in changelogs (which could defintely be called a "lie of omission").

I don't think anyone disagrees with the fact, that even if such knowledge was in the changelog, many bugfixes, would not be known by the dev(s) to be security fixes as well - and as such, one will never be able to simple grep for a "Security fix" or similar in changelogs to know when to upgrade to stay secure - such is the world of computers today :)

I don't recall accusing anyone of dishonesty and lying, but if I'm mistaken, I'd be glad to have a pointer. Cheers.

If you're smart enough to exploit a bug of a certain type - you'll be looking at the code(!) for any lines of C - that looks like the certain bug you want to exploit. I would like to hear of a person - smart enough to actually write an exploit, but dumb enough to be helped by information of security impact in changelogs? Pls. - just find me one, who can actually write an exploit, who thinks he/she is helped by such a msg in a changelog :)

As you may have gathered, I see no reason for actively excluding available information of bugs having a security impact.

Anyone dumb enough to think because it sometimes says along the lines of "security impact" in the changelog (which it actually already does some times AFAIK) - they should only upgrade when that's the case - is already doing their job horribly - and won't be worse off, if any relevant information was actually in the changelogs.

actually no, what i contend is your assertion of there being 'very, very few' commits fixing a bug with a known security impact to be of relevance. have you got evidence for this assertion?

> Then prove me wrong by showing lots and lots of examples of patches
> where the developer did know the security impact.

this is tangential, but i actually did provide examples in the past, here on LWN, in threads you also participated in so let google be your friend if you really want to see examples.

> The "apply important fixes" angle is presumably well covered by the
> stable kernel series.

i guessed you'd bring this up but it means you also shoot yourself in the foot ;). you see, there's a contradiction in your statements. according to you:

> Count me in the camp with "any kernel bug that can't be shown to be
> absolutely neutral with respect to results is a security bug."

that implies that most of the bugfixes must be backported to -stable but we know that's not the case. therefore either -stable doesn't apply all 'important fixes' (including security fixes) or most bugfixes aren't security related as you claimed before. which is it?

> Your second point is pure nonsense, ext* (and a lot of other classes of
> patches) are important. Nobody is advocating suppressing any class of
> patches, just flagging commits with potential miscreant atractors.

we aren't talking about suppressing patches per se (that'd be crazy), but important information in commit messages (security impact in general, file system corruption for the ext* case i brought up as comparison).

so you're admitting that there's a useful category of impact information that you would not advocate to suppress. that's a good step! now you'll have to explain why 'security impact' is different from 'filesystem corruption' in this regard. for that you'll have to explain how exploiting security bugs can never ever corrupt filesystems (else you'll have to conclude that at least some of the security fixes must be marked for filesystem corruption, which is enough to grep for, contradicting your other desire to make security fixes non-greppable), and also why helping miscreants to corrupt filesystems is a good thing (i.e., you can't use the same argument for contradicting purposes).

> Third, noone I heard of is trying to supress security information.
> Nobody is in any position to do so, in fact.

did you read the Linus mail (and the whole thread actually) i linked to? he admitted it.

> What I do see is efforts to fix security bugs, and get the fixes out to
> anybody affected as soon as humanly possible, hopefully without alerting
> would-be miscreants beforehand.

how can they be fixing security bugs when they don't even know what bugs have a security impact? or are you now praising selective fixing of bugs?

> And yes, LWN's security errata page is a part of this effort.

so when kernel devs put security impact info into a commit it's a bad thing but when LWN points at the same commit it's a good thing. i think you want to try this one again.

> I never said exploits are written as you say, so this point is moot.

but you did, even in this latest response in yours:

> [...]hopefully without alerting would-be miscreants beforehand.[...]

this statement means that you assume that people can write exploits *because* they read about exploitable bugs in the commit message. that is, you're claiming that to exploit a kernel bug one has to read about the fact that a given commit fixes it, and magically the exploit appears out of thin air.

in the reality out there, people writing exploits couldn't care less about what the commit message says about the security impact, instead they'll look at the actual code and decide based on that. in other words, your justification to cover up security impact information in commit messages doesn't stand on any legs so far.

> Security through obscurity works as long as the attackers are in the
> dark, which will usually be for a limited time only.

have you got evidence that attackers are in the dark when all they can rely on is the code in a patch (vs. the commit message)? as a sidenote, i'd like to hear your theory on how 0-day exploits are written 'cos they certainly can't be based on any security related information in the commits.

> AFAICS, there are clear negative effects (miscreants grepping,

you haven't shown any evidence for this.

> "only apply flagged security fixes" mindset)

you haven't shown any evidence for this. (see a theme here? repeating the same statement without evidence doesn't make it any more true)

> and few (if any) positive ones,

you must be out of your mind if you think that making security fixes public has no positive outcome. what else on earth would allow people to fix their systems?

> so the net result would be a loss.

since all the premises for this conclusion have yet to be shown to be true, the jury is still out on this one.

> You clearly see it otherwise, but haven't shown any positive result of your proposal.

it's not my proposal, it's what most of the rest of the world does (heck, even the linux world, just ask any distro maintainer how much they appreciate that they have to reverse engineer security impact information from kernel commits).

Some fixes are even made before a CVE is allocated. Since commit messages are not changed after the fact, the git log is not a good place to keep a canonical mapping for CVEs to commit names. Good thing the CVE database exists, huh?