Ever since Munki added support for Notification Center notifications, people have reported issues, in some cases, that clicking on a notification did not cause Managed Software Center to launch.
In some/most early reports of this issue, it seemed to be triggered by signing the MSC app, perhaps in some specific way. But it was hard to reproduce and many Munki deployments (mine included) did not seem to have the issue.
But with the advent of Apple silicon Macs, this issue is now, it seems, widespread. It seems pretty consistent that clicking on a notification on an Apple silicon Mac does not cause MSC to launch. (It will be brought forward if it’s already open in the background).
After spending some time poking at this issue recently, I’ve come to the conclusion that changes to macOS have broken a technique used by munki-notifier — at least on Apple silicon. I have a suspicion this is because all code on Apple silicon must be code-signed — and adhoc signing counts as code signing.
munki-notifier is a small Objective-C app that exists only to send Notification Center notifications or launch Managed Software Center. In order to show the Managed Software Center icon and appear as “Managed Software Center” in the Notification Center, it performs what is definitely a hack: at runtime it pretends its CFBundleIdentifier is “com.googlecode.munki.ManagedSoftwareCenter” instead of the actual “com.googlecode.munki.munki-notifier”. Since Apple provides no supported way for a helper app/process to post a notification for a main app, this hack causes the OS to treat munki-notifier as though it were Managed Software Center when posting notifications.
My theory is that with code signing in place, the OS sees that the app it tries to launch (the real com.googlecode.munki.ManagedSoftwareCenter, usually located at /Applications/Managed Software Center.app), is not the same app as the app that posted the notification (munki-notifier.app
, usually located at /Applications/Managed Software Center.app/Contents/Resources/munki-notifier.app
) and decides something is fishy and refuses to launch MSC.app.
In this situation, the unified log will have messages like:
2022-04-24 08:14:27.429196-0700 0xc5a308 Error 0x0 1468 0 usernoted: [com.apple.unc:application] Failed to find appropriate application to launch for com.googlecode.munki.ManagedSoftwareCenter matching F023EF36-12CC-4CB3-B27D-E97F53386B32
(I use `sudo log stream --info --debug | grep usernoted` to monitor the log messages around this)
Two solutions to this issue occur to me.
1) Get rid of munki-notifier altogether and incorporate its functionality into MSC.app. Doing this such that MSC.app does not display a icon in the Dock or a menubar until it has decided at launch whether it is going to post a Notification Center notification or just launch normally is probably possible, but complex, and possibly also a bit of a hack.
2) Get rid of the CFBundleIdentifier spoofing hack in munki-notifier. munki-notifier would just post notifications under its own bundle ID. When a notification is clicked, munki-notifier is launched again, and it, in turn, reacts to the clicked notification and launches MSC.app.
The second solution works, but has some UI/UX and administrative/management issues:
1) Notifications show the icon of the app that posted the notification. If we want notifications from munki-notifier to display the MSC icon, we must duplicate the MSC icon and make that the icon for munki-notifier. (This has implications for admins and tools that “re-brand” Munki: they might have to be updated to handle this new icon. Perhaps some clever symlink could be done in order to have a single copy of the icon)
2) If there is no config profile in place, the first time munki-notifier tries to post a notification, the user will see something like “munki-notifier wants to send notifications”, and in the Notification Center preferences pane, munki-notifier will show up as “munki-notifier” and not “Managed Software Center”. This can be addressed by configuring localized display names such that the display name for munki-notifier.app
is “Managed Software Center” (or equivalent name in whatever local language). This also has implications for admins and tools that “re-brand” Munki.
3) If you currently use a configuration profile to make sure MSC Notification Center notifications are approved/allowed, you’ll need a new one for com.googlecode.munki.munki-notifier.
4) Any machine that was running an earlier version of Munki and then upgrades to a future version with these changes will likely have two entries for “Managed Software Center”:
(One is for com.googlecode.munki.ManagedSoftwareCenter, and the other is for com.googlecode.munki.munki-notify)
It occurs to me that we might be able to avoid the double entries in the Notification Center preference pane, the need for a new configuration profile, (and a prompt for approving the notifications if you don’t use a config profile) by changing the CFBundleIdentifier of munki-notifier to com.googlecode.munki.ManagedSoftwareCenter, and changing the CFBundleIdentifier of Managed Software Center to something else, like com.googlecode.munki.ManagedSoftwareCenterUI. But that is likely to trigger other issues, so I’m not convinced it’s the right approach.
So I’m asking for thoughts and reactions to what is likely to be a moderately disruptive set of changes in order to get Notification Center notiifcations properly launching Managed Software Center.app.