Re: Deferring native compilation finalization until idle

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

> > From: "Aaron Jensen" <[email protected]>
> > Cc: "Perry Fraser" <[email protected]>, "Eli Zaretskii" <[email protected]>,
> [email protected], [email protected], [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?
>

codesign affects the bundle produced in nextstep/Emacs.app.  Emacs must be
run from that bundle (or installed bundle) to effect the opt out for the
main binary (and I think its descendents).  Binaries produced by libgccjit
are not opted out by themselves.