[+] drama (attempting configureProjectForLd)

Core/Target/platform.lua

@@ -14,6 +14,7 @@ local platforms = {
         devChainRequiresElfStrip = true,
         devChainSupportsElfStrip = true,
         devChainCoreUtils = true,
+        elfSupportsRPath = true,
         exts = {
             SharedLib = ".so"
         }
@@ -25,6 +26,7 @@ local platforms = {
         devChainRequiresElfStrip = true,
         devChainSupportsElfStrip = true,
         devChainCoreUtils = true,
+        elfSupportsRPath = true,
         exts = {
             SharedLib = ".so"
         }

Core/project.lua

@@ -185,6 +185,77 @@ local function configureProjectForTarget()
     auRequire("Core/Target").startProject()
 end
 
+local function configureProjectForLd(prj)
+    -- I'm not going to deal with this argument
+    -- 
+    -- I don't care for the opinions of greybeards who are stuck in the opinions put forth by AT&Ts meme of an OS
+    -- In *NIX land, you have +X, use it. I don't want to hear about how operating systems that have more aggressive
+    -- executable policies than macos and windows, with their vast ecosystem of file system sandboxing extensions, 
+    -- can't cope with loosely following the intentions of the NT loader for the sake of uniformity across platforms.   
+    -- 
+    -- https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications
+    --
+    -- inb4 LD_LIBRARY_PATH screeching as if users should be expected to mess around with env vars before launching
+    -- each application. no, just no.
+    -- 
+    -- inb4 muh security. A malcious dependency injection would be the product of a hostile manipulation of the accessible
+    --  file system files and/or directories. Both are systematic issues we aren't going to make a dent in. The latter being
+    --  the fundamental issue your administrators should be focused on mitigating; sandbox all apps that could perform hostile IO.
+    -- If an attacker can write a malicious module or system lib proxy somewhere, you've failed basic attack mitigation,
+    --  and you're going to be pwned on non-POSIX targets no matter what. 
+    -- Elevation exploits shouldn't be a problem so long as the linkoptions order is maintained so that $origin and then 
+    --  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
+    --  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 
+    --  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).
+    --
+    -- Change my mind (without parroting what some dude said on some forum over a decade ago)
+
+    if (prj.projectType ~= "SharedLib" and
+        prj.projectType ~= "WindowedApp" and
+        prj.projectType ~= "ConsoleApp") then
+        return
+    end
+
+    if (not Aurora.Settings.bForceWin32EscLd) then
+        return
+    end
+
+    auFilterForConfigPlatforms(function(config, platform, arch)
+        local platform = Aurora.Platforms[platformName]
+        if (not platform) then
+            return
+        end
+
+        if (not platform.elfSupportsRPath) then
+            return
+        end
+
+        linkoptions { "-Wl,-rpath,'$ORIGIN'", "-Wl,-rpath,'/lib'" }
+        
+        if (arch == "x86_64" or arch == "arm") then
+            linkoptions { "-Wl,-rpath,'/lib64'" }
+        elseif (arch == "x86_32") then
+            linkoptions { "-Wl,-rpath,'/lib32'" }
+        end
+
+        linkoptions { "-Wl,-rpath,'$PWD'" }
+
+        linkoptions { "-Wl,-rpath,'/usr/lib'" }
+        
+        if (arch == "x86_64" or arch == "arm") then
+            linkoptions { "-Wl,-rpath,'/usr/lib64'" }
+        elseif (arch == "x86_32") then
+            linkoptions { "-Wl,-rpath,'/usr/lib32'" }
+        end
+    end)
+end
+
 local function setupProject(prj) 
     print("project", prj.name)
 
@@ -205,6 +276,7 @@ local function setupProject(prj)
     configureProjectForPlatforms(prj.projectType)
     configureProjectForTarget()
     configureProjectForDebug(prj)
+    configureProjectForLd(prj)
 
     defines "_AU_HAS_ATOMIC_INTRINS"
     defines("_AU_BUILDING_" .. string.upper(prj.projectType))
@@ -270,7 +342,7 @@ local function setupProject(prj)
     end, root)
 
     buildHooks.startProject(prj.name, prj.projectType)
-    
+
     auForEach(prj.dest, function(v)
         addDest(prj.name, prj.projectType, v)
     end)

Public/settings.lua

@@ -102,6 +102,8 @@ auSetDefault(settings, "bForceClangWin32", false)
 -- G++ is a mess whose future I don't care for. Not that libc++ doesn't do stupid thing on Linux, but au runtime takes care of a lot of things, so idc.
 auSetDefault(settings, "bForceLLVMStl", true)
 
+auSetDefault(settings, "bForceWin32EscLd", true)
+
 -- Premake5 binary name to look for when when tied into cmake. Used by build actions and other lua scripted features
 auSetDefault(settings, "sDefaultCmakePremakeBin", "premake5")