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

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

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

You are right about the sealing itself: Info.plist is covered by the code signature, deliberately, so that a modified program cannot keep the identity (and the granted permissions) of the original. Editing the file and re-signing is technically possible with Apple's developer tools, but the result counts as a different program: the permissions the user had already granted are dropped, Gatekeeper may refuse the bundle depending on how it was installed, and the next Emacs upgrade silently undoes the edit. It is an escape hatch on the level of patching the source and rebuilding, not something users are expected to do.

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).

---

I hope that makes sense. In any case, thanks for raising these questions and concerns.

Cheers,
[email protected]

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

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