Re: Deferring native compilation finalization until idle

> From: Stéphane Marks <[email protected]>
> Date: Sat, 25 Jul 2026 18:43:02 +0200
> Cc: Aaron Jensen <[email protected]>, [email protected], [email protected], 
> 	[email protected], [email protected]
> 
>  TBH, I don't understand why that validation is need for *.eln files.
>  Those are compiled on your machine, so what validation is necessary?
>  It's not like you download unknown binaries from somewhere.
> 
> Per
> https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.disable-library-validation?language=objc
> 
> 
> "The Hardened Runtime enables library validation by default. This security-hardening feature prevents a
> program from loading frameworks, plug-ins, or libraries unless they’re either signed by Apple or signed with the
> same Team ID as the main executable."
> 
> This includes the native modules produced by libgccjit.  I suppose that unless and until libgccjit binaries can be
> signed as the bundle is signed (assuming people are running from a bundle), scanning will always be done
> without the OS-level opt out.

I know how these features work.  What I'm saying is that
security-checking binaries produced on the same system makes no sense,
so directories where these files are generated (such as the tree where
Emacs is routinely built) should be exempt from the check, by whatever
means the system lets you use.  Likewise for individual binaries and
shared libraries you build yourself on the same system.  And *.eln
belong to this category.

IOW, my "I don't understand" is not to say that I don't understand why
the OS does it, it's to say why working around that is not TRT.