Doesn't sound the least bit snarky. Submitting small patches isn't unreasonable, and GRSecurity-inclined people would do well to play nice with the kernel dev process.

Rather attempts to submit it in smaller patches have been met with disinterest. As well as the fact security in general has the appearance of being sidelined by the core developers - which has created a large disincentive for developers interested in getting GRSecurity upstreamed from even trying (again).

1. Saying that since no one has yet "paid for a team of people to do it" then it "must not be worth doing"

2. Sarcastically using info leak in quotes (see KASLR post in my original email for context on info leaks)

3. Repeatedly saying: if you discover a problem "I can help out with that" or "just let me know" when there is a long history of people doing exactly that and linux core devs including Greg K H largely ignoring them.

Etc, I could go on.

And this is all politics. I never said I was apolitical in the posts above. The whole reason people are saying it would take a team of people to submit patches is because politics.

Except that it's much less declarative than you're stating ('kind of implies' is pretty far from 'must'), and even has an emoticon added to indicate commiseration: "kind of implies that no one thinks it is worth doing :(". I agree that context can be missing, but at the same time, you shouldn't be significantly changing the visible context like that - you seem to be more about projecting your own issues rather than reading what's on the page when you do that.

A nicely ironic reply, though - if you do actually have problems with the way they behave, why invoke their behaviour to defend your own?

I remarked on his snarkyness simply because it indicative of the problem: there has been a long history of dismissiveness during any discussion of upstreaming PaX/grsec-style mitigations. So considering it is not being taken seriously we will continue to enjoy the side-effects for the foreseeable future.

PaX/grsec is in a different class of mitigation. I don't really know any competitors besides other implementations of small subsets by different operating systems or hardware manufacturers.

To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.

No major distro carries the patch, and the kernel devs don't want to merge it as it is.

A change in tactics is needed - make it easier for everyone to see how much better things with grsec are. The tweets are good, a summary of those tweets would be better.

Then to get all smug about it and call politics on people for doing a code review, rather than fix the patches or communicate their importance better... They could be doing good work but I don't think they come off well in these threads.

Really I think it comes down to territoriality. If there was no 'grsecurity' or 'PaX' name or team or whatever, and it was just a random dev submitting a simple feature, they would accept it. But when this other entity comes trying to improve upon their flawed system, suddenly ego gets involved.

I don't mean to rag too hard on the core devs, but many of their decisions are based on gut instinct, which is very frequently misguided or wrong (heuristics are evolved for reacting quickly to emergencies, not making logical decisions). Grsec should have been introduced into the mainline years ago. The Linux kernel's security track record is embarrassing.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kerne...

I value my privacy more than most. But when you are contributing code to a public project used all over the world by millions of people, you should at least be willing to identify yourself, or have very good reasons for not doing so. And that's before we get to the nontrivial copyright issues.

For example, PaX was the first person to implement ASLR for Linux... and that was adopted into the Linux Kernel many years later (as well as by Windows, OSX, and other BSDs). https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

The person or entity submitting the code should be irrelevant. Exacting code review and testing establish the code as trustworthy or compromised, not the identity of the author.