This question is often raised, so I'm creating this sticky post that I can point to as a response to future requests.

Regarding the use of grsecurity on old, unsupported kernels: I don't publish the full set of old patches specifically because I don't want to encourage the use of old, unsupported kernels. I've heard every excuse -- but the simple truth is that there are classes of vulnerabilities for which grsecurity will do little to nothing; running a kernel with such known vulnerabilities defeats the purpose of using grsecurity. Likewise, not only are these kernels either unsupported or inadequately supported by upstream, but we will not spend any time supporting anything but what is on the website.

We used to have a large problem with users reporting issues that had long been resolved without mentioning up front what kernel they were using. Since removing all patches but the ones we support, such reports have been much less frequent.

Regarding the use of third-party ports of grsecurity to other kernels: porting to a different codebase isn't just a "patch and fix up the compile" job. What different features exist in the other codebase? Has grsecurity been properly modified to work with those features or differences in a way that preserves the intent of our software? I'd personally never use such a patch for this reason.

If you're "forced" to run a particular old kernel, instead evaluate the reason why you are "forced" to do so. Most likely it is due to some other smaller patch (in comparison to the ~4MB grsecurity patch) that you should look into having forward-ported instead of degrading the quality of the entire kernel by continuing to use kernels that haven't seen any updates at all in several years.

I feel that it should mean something to use grsecurity, not just that you ran patch < some.patch. It should be as part of legitimate attention to security, and not as an enabling mechanism for shirking responsibility or as just another checklist item.