The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended: https://grsecurity.net/passing_the_baton.php https://grsecurity.net/passing_the_baton_faq.php I'll be clearing out the AUR packages for PaX and grsecurity soon since the current 4.10 patches are not accessible. Providing out-of-date packages with known vulnerabilities and without the current set of mitigations is infringing on how they want their trademarks used. If people want to maintain forks, either a 4.9 LTS or porting it forward to newer kernels, they'll need to make a new project with a new name rather than using "PaX" or "grsecurity" as the naming. If it's serious and done by people that know what they're doing, official support for it can be considered. There are few people that are capable of truly taking over maintenance of the whole patches and I expect that they won't have time to do it. Don't be optimistic about this happening. There are no viable alternatives to PaX and grsecurity. Their focus is on kernel self-protection i.e. protecting the kernel from exploits, and we don't have anything for users to migrate to from these. There are plenty of alternatives to grsecurity RBAC but that's only a small portion of what the patches provide. Any form of access control (whether it's MAC, containers, uid/gid separation, ACLs, etc.) can be entirely bypassed with a single kernel exploit, so the only good way to use other MAC implementations like TOMOYO, AppArmor or SELinux was with grsecurity. We don't actually provide official support for any of these alternatives, but it's all little good without a hardened kernel anyway. A small subset of the kernel self-protection features have landed upstream as part of the Kernel Self Protection Project. The core/linux package doesn't enable the bulk of these features, and it probably doesn't make sense for it to turn everything on because a subset of them do have a significant performance cost. It would be possible to provide a linux-hardened package doing that but it would only offer a tiny portion of the kernel self-protection that grsecurity does. I may end up doing that, along with enabling support for all of the LSMs, etc. there but it's really not at all comparable to what has been lost. The LSMs are also little good without people working on providing userspace integration and policies for them. There are no good answers here. It would be possible to maintain a fork of grsecurity, especially if all kernel architectures other than x86_64 (and arm64, but it's not currently supported) were dropped along with grsecurity RBAC and anything that has a proper equivalent upstream. i386 and armv7 can still be supported as userspace archs, since dropping them as kernel archs is what would save most of the maintainance work and would eliminate a bunch of complex code only currently fully understood by the PaX and grsecurity authors. It might also make sense to start dropping support for old CPUs, beyond just only supporting 64-bit kernels. Intel Broadwell and later provide SMAP and there's also SMEP, so those could be used as substitutes for UDEREF and that portion of the KERNEXEC feature. The problem is that there aren't capable people with the time and willingness to dedicate a huge amount of their time to a volunteer project without pay. I already maintain/develop hardened Android LTS kernels as a significant but overall quite small part of CopperheadOS. It's not comparable to this because it's my job. I spend far more than 40 hours a week on CopperheadOS, and it's actually quite a relief to not need to worry about maintaining PaX and grsecurity for Arch Linux anymore especially since I had to do it on my own. I've been aware that the test patches becoming private was a very real possibility even before spender started talking about it on IRC weeks ago, so it's really not a surprise.