> And yet a dichotomy that you gave me earlier in the same context[...]
> [...]you refuse to respond for fear of disclosing your hypocrisy.
the problem is that i explained to you more than once already that what you so desperately tried to describe as a standalone 'security fix' wasn't that (if you want to argue about *this* then present your arguments). therefore i won't deal with the conclusion until you fix this false premise. little hint: repeating the same thing doesn't make it true, try a better route.
> It is clear that you do not intend productive discussion.
right, because your not answering the following questions previously was a clear attempt at a productive discussion:
1. you didn't show what 'all bugfixes' are. i asked you for a specific example and you evaded it with some hyperbole. that's not a productive discussion dude. you either answer with a list of git commits or you admit that you cannot produce it. which is it? (rhetorical question, i'm sure we both knew from the beginning that it is not possible but you have yet to come to terms with that since it means that your entire premise was false).
2. you didn't show how commits not adding new features cannot introduce bugs (else your algorithm for producing 'all bugfixes' is wrong). once again, i'm sure we both know that non-feature commits do at times introduce bugs so your algorithm is actually wrong (and as a side question, you didn't tell me how to decide what is a feature commit and what isn't). you have yet to admit that and you have yet to fix your algorithm (or admit that you cannot produce it).
3. you pretend to not understand that when you 'applied fixes for all the security bugs in the system' you actually didn't apply all. you yourself explained why that wasn't the case so forgive me if i stopped watching you argue with yourself ;). i'd also add that your case of applying fixes at your company is not at all like the case we've been discussing here (closed vs. open source systems, applying vendor blobs vs. backporting patches, you get the idea). i didn't point that out so far because i hoped you'd understand that even your own case has no standing, but seemingly i have to make this step now and ask you to explain what relevance your situation has to the one we've been discussing at all.
4. you have yet to explain why it is a bad idea to apply this particular fix (you know, the whole topic is still centered around the /proc/pid/mem problem) on its own (vs. applying any and all *other* fixes as well that went into 3.3-rc1). why did you evade that question? because it's what a productive discussion makes? or because you'd have then to explain why all the fixes that went in *after* 3.3-rc1 (where some of the problems were *introduced* by 3.3-rc1) should have been avoided in the first place (remember the 'all fixes' you were supposed to produce and that in hindsight should not have contained these fixes that needed later fixes)? let me guess, the productive discussion of this will result in your *not* responding to this in any meaningful way.
i could go on and on where you simply passed on the inconvenient admissions, but i think everyone's getting tired of this (myself included). if you think you have actual arguments to present to the above questions, go ahead. otherwise, yours will be the last word, i promise ;).
now let's see the real meat, the Linus commit and associated coverup.
> Again, show me where Linus concealed the security impact[...]
easy, you just said the word that doesn't even occur in the commit message, there's nothing even remotely related to the local root hole in fact.
> I see Linus in the fix commit telling us that the permission checks
> on /proc/pid/mem are faulty[...]
you do see that. grep doesn't see the word 'faulty' in there (but that relates to /proc/pid/mem handling, not the 'permission checks'). i do see 'not very robust' only. let me not bring up the dictionary again to explain why the two words/expressions don't mean the same thing. not to mention that neither has *any* connotation with 'this is a security bug'. and they most definitely don't mean 'easily exploitable local root here'.
> [...]and don't behave like other permissions checks.
sadly for you, this doesn't imply 'local root hole here' either.
> if you are not clueful enough to recognise that "permission checks are
> faulty" is a sign of a potential system security flaw[...]
sadly for you, the commit message doesn't say that. what it does say is that said checks were *different* from checks done elsewhere. whether that's a bad or good thing is left for one's imagination, you most definitely do not learn it from Linus.
but the bigger problem with your statement above is that it implies that commit users (as i said already, that's mostly distros, companies, etc) are supposed to somehow divine the *actual* meaning of the commit from *clues* vs. learning of them directly with no coverup. are you *nuts*?
> [...]you are the sort of person who is likely to blindly take
> individual "security" patches without thinking about the complete
> systems context[...]
i think you want to rethink this logic here. if one's not clueful enough to recognise the clues in this commit message then why would one blindly backport this commit? and if one's clueful enough to recognize the clues then why would one *not* blindly backport this commit? do you know of some issues that noone else does or talked about so far?
> I've already given you an example of a case where that behaviour pattern[...]
no, you didn't. read my contests of that claim and *respond* to them (yes, it bleeds from many wounds). pretty please?
> I do not understand why you wish Linus to encourage people to blindly
> apply patches without considering each in terms of the system security.
1. according to you Linus did reveal the security nature of the commit for the clueful (and i certainly hope you'd count distro maintainers, etc there), therefore he already committed (no pun intended) the sin of "encourag[ing] people to blindly apply patches without considering each in terms of the system security". where do i come in here then?
2. you didn't show which kernel commit users "blindly apply patches without considering each in terms of the system security". name them and shame them, the world, especially their users, deserves to know.
3. you haven't shown why properly describing the nature of fixes "encourage[s] people to blindly apply patches without considering each in terms of the system security". before you bring up your company example again, consider that we're talking about linux kernel commit users here, not (seemingly) clueless company employees and proprietary(?) vendors.
> that security is rarely the most important thing people seek in a system
this is a completely irrelevant statement, what argument is it supposed to support? you don't fix bugs, security or otherwise, because something is the 'most important thing', you fix them because they cause problems for you. if they don't, then you don't care, regardless of what 'the most important thing' in your life is.
> [long <something> that's not worth yet another long subthread now ;] it does not
> follow that security bugs should be called out over any other type of bug.
i'm totally with you on this one! i do not want any *special* treatment for security bugs, i want them to be treated like any normal bug! you know, where the commit message describes what the bug is. say, when you have a filesystem corruption bug, the commit fixing it does say so instead of 'clues' that you could divine from the true nature of the fix if you are clueful enough. see, you were agreeing with me all the time, you want security fixes to say 'security fix' as much as you want filesytem corruption fixes to say 'filesystem corruption fix'. as things stand now, the latter happens and the former doesn't, that's what i'd like to change! and please don't make me sad by saying that filesystem corruption fixes should not be called out as such because that would "encourage people to blindly apply patches without considering each in terms of the" filesystem reliability.