I have an application that works in conjunction with a user-space CoreAudio driver (aka AudioServerPlugin) (see https://github.com/q-p/SoundPusher if you're curious -- it's open source). As far as I'm aware, these plug-ins are already sandboxed. How do I go about hardening / notarizing this plug-in? Note: This is a plug-in for the macOS audio system, not really my app (although my app will look for the sound-device provided by this driver and read from it). I assume notarizing the app itself (it's already code-signed and only needs "microphone" entitlement to access audio-input from my user-space driver) as well as the installer that contains both the app and driver happens as usual...?
Thanks Quinn, I (think I) got it to work... It is a flat-package (`.pkg`) installer. I was unclear on how the notarization for an installer package works (in that it is only used as a container that can contain multiple items to be notarized), but after figuring out I can just upload the .pkg (and don't have to notarize the contents separately) I eventually got it working.
Biggest hurdle was figuring out how to ensure that `--timestamp` was included while code-signing (=> `OTHER_CODE_SIGN_FLAGS`), as that is needed for some included .dylibs.
Then I had to learn the hard way that entitlements for sandbox and hardened run-time access are separate, and that one should not enabled the "Hardened run-time" project-wide, but only for individual targets (otherwise the entitlements are not handled correctly by Xcode's Capabilities UI).
One thing I'm slightly unclear with the stapling, though:
I have a ticket that covers the installer and everything it contains. I can staple the ticket to the installer, as well individual copies of the included app & driver. *But* the copies of the app & driver included in the installer obviously are not stapled (only the installer is). Can this be a problem?
