flink() at last?

The main point was the complete absence of any mention of security impact in the commit message (what the "censorship" of disclosure) was referring to. Choosing not to attribute it as well was just the icing on the spite cake.

Here are the facts:
I reported this directly to Petr on IRC
I had already fixed the vulnerability myself in the one affected grsecurity patch the night before, with an unmistakable commit message
Security impact was known at the time the patch was created
A CVE had already been allocated prior to the patch being created

No CVE or impact at all was mentioned in the commit
It seems that despite a bug being a bug (according to Linus) the advice from Andrew Morton (https://lkml.org/lkml/2012/6/13/502) continues to be ignored quite often specifically for security vulnerabilities
https://git.kernel.org/cgit/linux/kernel/git/stable/linux...
Everyone whose name appears on that commit is complicit in the behavior, no matter what they say about how they really feel about the upstream security disclosure policies on private mailing lists or in private mail because they don't want to upset Linus' silent-fix campaign.

Since when does my sphere of responsibility extend beyond my own users? Any direct reporting we've done is not under any kind of obligation (of the kind upstream has to the code they distribute), and you should understand it in that context. We find and fix tons of problems in the upstream kernels, including finding many security fixes that fall through the backporting cracks (due in large part to the active cover-up policy) -- this is but one minor example because I chose to directly report it due to the apparent complete absence of QA regarding the use of unprivileged user namespaces. As I mentioned in my commit message, it's a trivial, 22 character local DoS (which I think may be the smallest ever reported).

Now, try hard to think about this as a smart person would: if some group were consistently finding vulnerabilities in my software, would it not be wise to monitor that code to spot those things, given that they're not being obfuscated at all? Apparently in 13 years, the Linux kernel devs still have not figured this one out. "That's work they shouldn't have to do!" a hypocrite might say. Yes, just as I shouldn't have to be scouring upstream commits (across all developers, not just us two, so there's quite some asymmetry of effort here) to find the silent security fixes falling through the cracks.

I believe in the old adage that actions speak louder than words. I've "joined the dark side" because I refuse to support and enable a system actively engaged in pulling the wool over your eyes as to the security of their code? Apparently as the arbitrator of ethics and morality, do you suggest I continue to piss away one-off vulnerabilities so they can be fixed in a one-off fashion with the associated coverup? Do you not see the long-term ramifications of that in pursuit of some short-term benefit?

-Brad