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

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