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 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?