AuroraPipeline/Build
1
1
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity

[*] Double-down on clang being shit

Browse Source
This commit is contained in:
Reece Wilson 2024-05-16 04:13:40 +01:00
parent 29a06dcbdd
commit 051e453cad
1 changed files with 16 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Core/project.lua
View File

@ -164,14 +164,19 @@ local function configureProjectErrors()
filter {"toolset:clang"}
buildoptions {"-fms-extensions"}
-- the fucking retard cunts behind clang acknowledge there's a 2x slowdown here.
-- not only that, GCC optimize("no-stack-protector") is broken, their ms stack guard check doesnt do anything, and there are
-- reports that enabling sanitization actually exposes side channel attacks. thanks freetards. very cool.
-- all this because you dont trust me to not memcpy a fucking user provided blob with a bad length check in the very few places that
-- have any reads/writes determined by potentially malicious remote user input. even worse, i've seen what should be nothing more than
-- leaf functions doing atomic bit tests and sets get infected with these shitty checks.
-- once again you freetards are 20 years behind commercial alternatives, and that's with infinite apple buxs.
-- if anything happens because of this, i hope somebody burns down a house of a freetard and shits on their doormat during the escape.
-- The fucking retard cunts behind clang acknowledge there's a 2x slowdown here.
-- Not only that, GCC optimize("no-stack-protector") is broken (ive tried other attributes), their ms stack guard check doesnt do anything,
-- and there are reports that enabling sanitization actually exposes side channel attacks. thanks freetards. very cool.
-- All this because you dont trust me to not memcpy a fucking user provided blob with a bad length check in the very few places that
-- have any load/stores, in or around the stack, as determined by potentially malicious remote/untrusted user input. Even worse, I've seen
-- what should be nothing more than leaf functions doing atomic bit tests and sets get infected with these shitty checks. Meanwhile llvm
-- devs are bitching that "NoOoo you're right, this is a bug, LTO shouldn't be stripping stack checks". Even when the compiler knows
-- the stack isnt being accessed and there's no control flow out of its' reach, these moron compiler devs are obsessed with injecting
-- their shit checks that wont catch any real exploit chain. I'm so fucking sick of these retard security grifters hung up on "MUH OBERFLOWS"
-- "MUH SAFE LANGS" without being able to define what the fuck their attack vector is or how it's going to be exploited. If we cared about
-- overflow checks, then we'd have mimalloc running in secure mode.
-- Once again these twats are 20 years behind commercial alternatives, and that's with infinite apple buxs.
-- If anything happens because of this, i hope somebody burns down a house of a freetard or llvm dev, and shits on their doormat during the escape.
if (not Aurora.Settings.bClangIsNoLongerAPieceOfShitCompiler) then
buildoptions {"-fno-sanitize=all"}
buildoptions {"-fno-stack-protector"}
@ -265,12 +270,12 @@ local function configureProjectForLd(prj)
-- system libraries are considered before any malcious user-installed libraries could possibly be loaded.
-- If you're running a broken arse system with missing protected libraries and you run software as write-level groups,
-- you have bigger issues than my 'lets treat POSIX systems more like NT for cross-compatibility and sanity' assumption.
-- If you're worried about ld.so running unsigned code, go complain to glib iq-lets who maintain ld.so and force them
-- If you're worried about ld.so running unsigned code, go complain to glibc iq-lets who maintain ld.so and force them
-- into developing actual .text and .rodata signature validation with respect to a global root-writable certificate,
-- instead of spreading the ball of responsiblity like hot-fucking-potato in a game of respecting the UNIX :tm: way
-- of doing things (IE, expecting the user to know how to lockdown vendor supplied packages, RO all LD_LIBRARY_PATHs
-- of doing things (eg: expecting the user to know how to lockdown vendor supplied packages, RO all LD_LIBRARY_PATHs
-- and other undocumented vendor paths, and do god knows what to harden specific softwares dumped without thought
-- across an arahic FHS/XDG tree, while the developers do jack shit to improve stability, maintainablity, and security).
-- across an arahic FHS/XDG tree, all the while developers do jack shit to improve stability, maintainablity, and security).
--
-- Change my mind (without parroting what some dude said on some forum over a decade ago)
-- Don't like it? Disable: Aurora.Settings.bForceWin32EscLd