Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 9:45 AM, Eli Zaretskii < [email protected] > wrote:

> 
> 
>> 
>> 
>> From: "Aaron Jensen" < aaronjensen@ gmail. com ( [email protected] ) >
>> Cc: "Perry Fraser" < perry@ frasers. org ( [email protected] ) >, "Eli
>> Zaretskii" < eliz@ gnu. org ( [email protected] ) >, yandros@ gmail. com (
>> [email protected] ) , rudolf@ adamkovic. org ( [email protected] ) , emacs-devel@
>> gnu. org ( [email protected] ) Date: Sat , 25 Jul 2026 16:42:52 +0000
>> 
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>> 
>> Yep, I hear you. I struggle to rationalize it somewhat as well. The thing
>> I fall back to is that disabling the security check in Emacs disables it
>> for *everything* not just eln files you compiled. But any other binary you
>> may load for any reason. At the point of time we are in where supply chain
>> attacks are a real threat, I don't feel comfortable disabling the checks I
>> have available to me, plus it could run me into legal trouble when it
>> comes to client obligations.
>> 
>> 
>> 
> 
> 
> 
> AFAIU, the "workaround" that codesigns the just-compiled *.eln disables
> the security check only for those *.eln files. Isn't that so?
> 
> 
> 
> 

I don't believe so, not per the documentation: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.disable-library-validation

It's about *loading* of bundles, not producing them. It disables validation for anything that the app loads. It does not make it pre-validate or disable validation for anything that the app may build.

This is why I was originally against including it in the PROBLEMS document. It's opening ones self up to an attack.