bug#81526: 30.2; Emacs.app lacks class-based TCC usage-description keys, crashing subprocesses that touch privacy-gated frameworks

> Date: Sat, 01 Aug 2026 06:43:26 +0000
> From: Boris <[email protected]>
> Cc: Stéphane Marks <[email protected]>, [email protected], [email protected], [email protected], [email protected]
> 
> > Shouldn't these changes be left to the end user of Emacs instead?  Why
> > should the upstream project second-guess what kind of security will
> > the Emacs process have when run on the end-user's platform?
> 
> These keys do not set any security policy, so nothing is decided on the user's behalf. A usage-description key grants no access and changes no behavior by itself. It is only the explanation string that macOS shows in its permission dialog. The allow or deny decision is made by the end user at run time, per service, and can be changed any time in System Settings. On GNUstep and other platforms the keys are inert strings.
> 
> Leaving the keys out does not leave the choice to the user, it takes the choice away: when a key is missing, macOS never asks and kills the process with SIGABRT as soon as it touches the corresponding framework. That is the crash in Mark's report. With the key present the user gets the normal system prompt, and denying it gives the process a clean "denied" status instead of a crash.

I'm asking whether the decision to allow the choice is not already a
user-level decision.  If the platform decided that the default should
be to abort the program, why should the Emacs project decide we want
to override that default?

> The end user also has no practical way to add these keys locally. Info.plist is sealed by the code signature, so the keys have to be in place before the bundle is signed. Editing the file of an installed Emacs.app invalidates the signature, and macOS then treats the bundle as a different (or broken) app and drops permissions the user already granted. Build time is the only reasonable place to do this. That is why iTerm2 ships these keys, and why Emacs itself already ships the same kind of keys for the Desktop, Documents and Downloads folders (bug#37551), for AppleEvents, and for speech recognition. The patch I posted earlier in this thread only extends that existing mechanism to the remaining services.

Isn't there any way for the user to modify the keys and then re-sign
the modified keys?  How do users go about these issues in other cases?
It sounds incredible that the list is sealed at program build time and
cannot be modified by the user, because I imagine most programs on a
typical macOS system are not built by the user on that system, but
installed in an already pre-built form.  If this stuff can only be set
at program build time, it would be impossible for users to allow that
after installing the program.  Or what am I missing?