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

> It is IMNSHO incorrect, almost preposterous, to ask for Emacs to
> declare any and every service the platform might have, just because
> Emacs has commands that start sub-processes.  Other programs have
> similar capabilities.  Does Make, for example, declare all such
> services in its Plist.info? does Less? do Vim and its variants?

No, and macOS never asks them to. Make, Less and Vim are plain executables; they have no Info.plist and nowhere to declare anything. When a process touches a gated framework, macOS does not look at that process's own files: it walks up to what it calls the responsible process, the app bundle hosting the process tree, and consults the declarations there. Run Vim inside iTerm2 and touch the microphone - and it is iTerm2's keys that get consulted and iTerm2's name that appears in the prompt. Make and friends are always guests; someone else's Info.plist answers for them. Emacs.app (specifically macOS application, not the binary) is never a guest in its own process tree. It is the host, so its Info.plist is the only place these declarations can live.

Let me also correct something I said earlier. It is not true that every terminal emulator ships these keys. Apple's own Terminal.app ships none, and still gets prompts ("Terminal would like to access the camera"), because (at least to my understanding/reading of the situation) the OS treats its own platform applications specially. But third-party applications get no such treatment; that is why iTerm2 and every other terminal emulator declares the full set, and why Emacs crashes today.

> But where do we draw the line?  Since Emacs can invoke arbitrary
> programs, it sounds like you are telling we should declare all the
> possible services out there.  Why?  Users can always invoke those
> programs outside of Emacs, right?

The line is drawn by Apple, not by us. The class-based services form a closed list of about ten categories, and the patch declares the rest of that list as it stands today. Emacs already ships six keys of exactly this kind (AppleEvents since 2018, the folders since 2019, speech recognition recently), so this is not a new direction; it is finishing a fixed list we started covering years ago. The list grows by roughly one service per several macOS releases, and each addition is a two-line diff. Of course, I can't promise that Apple will not change this, though.

As for invoking the programs outside of Emacs: that argument would have applied word for word to the folder keys in 2019 (users can read their Documents with cat in Terminal), and we added those anyway. More importantly, much of what is affected is not a standalone program the user could relocate, it is Emacs plumbing. whisper.el does dictation by spawning ffmpeg to record from the microphone; that is exactly the kind of report that made emacs-plus start injecting the microphone key. Language servers are spawned by Emacs; running one elsewhere and connecting over a socket is possible, but it is a degraded and more limited setup. "The user could do it outside Emacs" is true of nearly everything Emacs does; it has never been our bar for anything else.

And look. I do understand the discomfort, and I share part of it: a text editor declaring camera and contacts strings feels like overclaiming, and the whole model is unpleasant from a Unix point of view, where a tool answers for itself. But leaving the keys out is not pushback Apple will ever notice (though who knows?). Its only effect is on Emacs users, who get a SIGABRT where users of every other macOS editor and terminal get a question or just a working application. And declaring is not requesting: nothing appears in any prompt or settings pane until some process actually asks for a service, and then it is the user who decides.

Cheers,
[email protected]

On Saturday, 1 August 2026 at 10:40, Eli Zaretskii <[email protected]> wrote:

> > Date: Sat, 01 Aug 2026 07:28:25 +0000
> > From: Boris <[email protected]>
> > Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
> >
> > > 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?
> >
> > There are two separate decisions here. What a program may conceivably ask for is a statement of fact about the program, and Apple requires whoever builds it to declare it. Whether to actually allow any of it is the security decision, and that one always belongs to the user, in the permission dialog, at the moment something really asks. The patch only makes the first declaration; it has no influence on the second.
> >
> > The abort is not the platform's default answer to the second question. It is the penalty for developers who skip the required declaration: Apple documents these strings as mandatory for any application that uses the corresponding APIs, and App Store validation rejects applications that lack them. Note also how inconsistent the failure modes are (camera aborts, location is silently ignored, local network prompts with generic text); this is enforcement of a missing manifest field, not a considered security default that Emacs would be overriding.
> >
> > The declaration is put on the developer because for a normal application the behavior is known at build time: a PDF viewer knows it will never open the camera, a videoconferencing client knows it will. Emacs is not a normal application in this respect. With M-x compile, shell, eshell and friends, what runs under Emacs's identity is whatever the user chooses to run. So the truthful declaration for Emacs is the one every terminal emulator ships: anything started in here may end up asking for any of these services, and the user is the one who should answer. Without that declaration the question never reaches the user; the process just dies.
> 
> It is IMNSHO incorrect, almost preposterous, to ask for Emacs to
> declare any and every service the platform might have, just because
> Emacs has commands that start sub-processes.  Other programs have
> similar capabilities.  Does Make, for example, declare all such
> services in its Plist.info? does Less? do Vim and its variants?
> 
> > What you are missing is that users never face this with other programs, because shipping these strings is the developer's side of the contract, and every application that uses a gated service ships them. The user-facing side (System Settings > Privacy & Security) can grant and revoke, but by design cannot add a missing declaration, since the string is the developer's justification shown in the prompt. When users do run into a program that lacks one, the fix has always been to ask the program's developers to add it. This report is exactly that, and it is the same way the folder keys got into Emacs in 2019 (bug#37551).
> 
> But where do we draw the line?  Since Emacs can invoke arbitrary
> programs, it sounds like you are telling we should declare all the
> possible services out there.  Why?  Users can always invoke those
> programs outside of Emacs, right?
>