We expect our 6.13 #grsecurity beta to be available within the next two weeks.

Our 6.12 #grsecurity beta is now available to beta testers for testing

@anderseknert Everyone who uses #AssholeLicensing like #SSPL or tries to infringe upon users' #FLOSS #Rights like #grsecurity & #RedHad do should be banned from any professional developments and supply chains as part of the #RiskAssessment and #RiskAvoidance in #DueDiligence.

• Anything else in criminal neglect at this point...

@prem_k @silentexception Well, #FLOSS does not require that they need to make it simple for one to do so.

Both #grsecurity & #RedHad comply to #GPLv2 by merely providing #paywalled access to their repos.

They don't need to provide instructions to make reproduceable builds nor documentation nor resources to do so!

Linux kernel hardening does not necessarily have to ruin performance. Quite the opposite is possible! One just has to address performance issues first and gets better security “for free” — sometimes vast performance improvements even!

Current example: BPF JIT handling. test_bpf.ko is a kernel module exercising various extreme and corner cases of BPF programs the kernel is supposed to handle just fine. However, under certain configurations it makes the kernel busy burn cycles without making real progress. Fixing that allowed us to implement security features in #grsecurity at all stages of the JIT process and basically get them for free. See for yourself…

…and yes, while waiting for insmod to finish on vanilla Linux, I fixed the tests and did a quick re-run on #grsecurity.

Performance isn't the enemy of security: we care about both. Today's patches finish off a set of security/performance improvements to eBPF. Below we show a ~30x speedup vs vanilla in running the eBPF selftests with every single #grsecurity option enabled!

@libreleah thanks.

Personally, I think maintainers should choose their license wisely beforehand:

• There are reasons why I chose to put some projects under #CCBYNCSA, some #GPLv3 and some #0BSD.

• In some cases I did fork stuff under #MIT which I'd not change the license of - even if it would be compatible - because I literally changed nothing in terms of code and also didn't see any advantage in doing so to begin with.

Espechally in the case of #DuckStation this is bad because we ain't talking about the whole #GPLv2-only vs. GPLv3+ drama or #grsecurity #paywalling (which is an asshole move but legal )...

• Maybe the dev(s) - unlike #Capcom - weren't fully aware of this issue, but even big Companies (i.e. #AVM) got forced into compliance...

Lets just hope a friendly (!!!) reminder makes them realize, apologize and undo the change...

I've submitted one #kernel #bug for #Linux and one for #HardenedBSD today, see: https://bugzilla.kernel.org/show_bug.cgi?id=219227 and https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/107 The issue is (almost) the same and breaks W^X. It has already been mitigated by #sydbox since version 3.15.1: #sydbox denies executable shared memory like #grsecurity does! See: http://man.exherbolinux.org/syd.7.html#Advanced_Memory_Protection_Mechanisms #exherbo

@carlwgeorge @vermaden @samurro @tara @vkc @BrodieOnLinux

OFC, #RedHat - like #grsecurity - is legally in the position to #paywall the #SourceCode access to paying customers only.

• That doesn't mean it's a good idea either way...

And they decided to kill #CentOS, because they don't understand that to make people and orgs buy #RHEL subscriptions, they've to provide value with those subscriptions, and many people decided that their offer isn't what they are able and/or willing to take.

@getimiskon @catsalad @alexadeswift @brouhaha yeah, #SubgraphOS got killed by #grsecurity being assholes and #paywalling access to their suite!

I wrote about how C‘s more recent language features make grsecurity maintenance easier and how we pushed the idea even further by adding a new compiler builtin.

https://grsecurity.net/reducing_maintenance_burden_by_bending_c

The article has quite some code snippets, showing how easy the latter actually is, thanks to a rather stable GCC plugin API.

#grsecurity #gcc #C

@marcan @fuchsiii kinda gives me #grsecurity & #RHEL - flashbacks:
cuz #paywalling #SourcecodeAccess to paying #subscribers and penalizing them aka. firing them as clients for exercising their right to share/modify/redistribute the #SourceCode is inherently an asshole move but apparently legal.

• Since #BrucePerens failed to sue #grsec into not doing that and #IBM took notice when they bought #RedHat.

Not shure if a #license that governs things beyond the useage rights of a #Software is even legally enforceable in Germany amd many other juristictions...

• I'd certainly rather blow €€€€ on a lawyer instead of playing "#FuckAroundAndFindOit" and facing insolvency-inducing "cease and decist letters" from competitiors by having flatout-illegal terms...

#WhatYouAllowIsWhatWillContinue

@the_moep Again: I've not tested / used / installed it yet so I can't formulate an educated opinion beyond: "Will keep it in mind as an option" ...

• I don't want to discount it, I'm just very wary of recommendations, as those have backfired on me, with #PorteusKiosk currently sadly "#Enshittifying" in a #grsecurity /#RedHat - Style by subsequently #paywalling even the most basic functionality and me having just gotten confirmation that basic functions like "#diskless clients" have been silently axed.

Sadly the #paywalling of #grsec / #grsecurity also killed more #downstream projects like tor-ramdisk which was a minimalist #busybox / #linux #distro designed to host #OnionServices. It was pretty nifty and the #SourceCode is still online and hosted by @torproject on their #gitlab, abeit seemingly abandoned since 2018...

@soulexpress nodds in agreement

• EVERY SINGLE ONE OF THEM!

Like there's a reason I only got a copy of #SubgraphOS as non-public alpha under the precondition to not redistribute and was allowed to preview it because that thing was unstable and had a lot of known issues the devs were working on to get fixed.

• It's not as if they weren't aware of those, but they also didn't want "#TechIlliterates" using it with a false belief in it being ready to use and trust in.

Not shure how #Subgraph evolved after #grsecurity decided to #paywall access to the #sourcecodes of said #patches and #tools cuz those were used in said distro as a means to harden it.

• But then again the #grsec devs seem to be so toxic, their entire Wikipedia Article got nuked and only an old archive version exists.

@Hyolobrika my guess is that @GrapheneOS is hell-bent on perfection or not bothering at all.

Kinda like saying #Linux is shit because there is no distro paying for #grsecurity and thus only #OpenBSD qualifies for them in terms of #security.

There are "compromises" and compromises: #GrapheneOS would rather mothball than back down and that's their right as a project...

I just think that keeps their adoption rate artificially low so #Google can shaft them and not face much Backclash...

@Hyolobrika @GrapheneOS

EXACTLY THAT!

I get why but the nonchalant attitude reminds me of #grsecurity and deciding to rather cancel that budge makes it a huge risk I'd not consider investing time, blood, sweat and tears into.

I think this rather sends the wrong signals and letting #GAFAMs and #Govware - #Backdoor integrators win.

Ideally we'd see @PINE64 , @olimex , #Fairphone and @frameworkcomputer look at #GrapheneOS and decide to make #secure & #repairable devices!

@GrapheneOS @matchboxbananasynergy And I guess noone has even dared to make a #DevBoard or #DevKit that does supoort #GrapheneOS and isn't a disassembled #GooglePixel...

Maybe @olimex or @PINE64 may be interested?

I mean I wished for better support of GrapheneOS, and I guess similar to #grsecurity, these hardening features are all intertwined and not optionalities one can choose to add or remove on a whim at build time...

@GrapheneOS I guess you gotta have to go like #grsecurity and maintain your own #fork of #Android?