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

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

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.

Cheers,
[email protected]

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

> > Cc: [email protected], Boris <[email protected]>,
> >  Alan Third <[email protected]>, JD Smith <[email protected]>
> > From: Stéphane Marks <[email protected]>
> > Date: Fri, 31 Jul 2026 19:55:44 +0200
> >
> > > ## Suggested fix
> > >
> > > Add the missing class-based usage-description keys to `nextstep/templates/
> > > Info.plist.in`, alongside
> > > the file-access keys already there. `NSAppleEventsUsageDescription` and
> > > the `*Folder*` /
> > > `*RemovableVolumes*` keys are already present and must not be duplicated;
> > > on master
> > > `NSSpeechRecognitionUsageDescription` is present too. Minimum useful set
> > > to add:
> > >
> > > - `NSPhotoLibraryUsageDescription`, `NSPhotoLibraryAddUsageDescription`
> > > - `NSCameraUsageDescription`
> > > - `NSMicrophoneUsageDescription`
> > > - `NSContactsUsageDescription`
> > > - `NSCalendarsUsageDescription`, `NSCalendarsFullAccessUsageDescription`
> > > - `NSRemindersUsageDescription`, `NSRemindersFullAccessUsageDescription`
> > > - `NSLocationUsageDescription`, `NSLocationWhenInUseUsageDescription`
> > > - `NSLocalNetworkUsageDescription`
> > > - `NSBluetoothAlwaysUsageDescription`
> > > - `NSSystemAdministrationUsageDescription`
> > > - `NSSpeechRecognitionUsageDescription` — **on the emacs-30 branch only**;
> > > master already has it
> > >
> > > That master already added `NSSpeechRecognitionUsageDescription` to this
> > > same template suggests the
> > > general approach is already considered acceptable upstream; this report
> > > just asks for the rest of the
> > > class-based services to be covered too.
> > >
> > > The `*FullAccess*` variants are the macOS 14+ replacements for the older
> > > Calendars/Reminders keys;
> > > declaring both keeps older systems working.
> 
> 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?
>