MSC and Notification Center: issues and options

217 views
Skip to first unread message

Greg Neagle

unread,
Apr 24, 2022, 1:25:28 PM4/24/22
to munki-dev, 'Gregory Neagle' via munki-discuss
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.

-Greg

Greg Neagle

unread,
Apr 24, 2022, 1:47:18 PM4/24/22
to munki-dev, 'Gregory Neagle' via munki-discuss
One of the details I forgot to include was that I was able to reproduce this issue using terminal-notifier (https://github.com/julienXX/terminal-notifier) with 

./terminal-notifier -message Foo -sender com.googlecode.munki.ManagedSoftwareCenter

Just like the reported problem with munki-notifier, clicking on the notification would bring MSC.app to the front if it was already open, but fail to launch MSC.app if it wasn’t already open.

alerter (https://github.com/vjeantet/alerter) juat hangs for me under macOS 12.3.1 on Apple silicon when attempting

./alerter -message Foo -sender com.googlecode.munki.ManagedSoftwareCenter

Yo (https://github.com/sheagcraig/yo) does not have an option to spoof the notification sender.

-Greg

On Apr 24, 2022, at 10:25 AM, 'Greg Neagle' via munki-dev <munk...@googlegroups.com> wrote:

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”:
<PastedGraphic-1.png>
(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.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/A809EFD5-A119-4A45-8C70-98D70216D423%40mac.com.

Dustin Davis

unread,
Apr 24, 2022, 2:08:38 PM4/24/22
to munk...@googlegroups.com, 'Gregory Neagle' via munki-discuss
Thanks for spending the time to investigate and share!

From my perspective, option two seems like the best path forward.

I think the administrative issues are reasonable and will not be a problem for us. My only (very minor) concern is the double entries for MSC in system preferences, but that is something we could live with. 

Dustin

On Apr 24, 2022, at 10:47 AM, 'Greg Neagle' via munki-dev <munk...@googlegroups.com> wrote:

One of the details I forgot to include was that I was able to reproduce this issue using terminal-notifier (https://github.com/julienXX/terminal-notifier) with 

Graham Gilbert

unread,
Apr 24, 2022, 3:08:53 PM4/24/22
to munk...@googlegroups.com, 'Gregory Neagle' via munki-discuss
I agree. I’ve not seen a single complaint over chrome’s two entries, so I think multiple entries is a non-issue really. 

From: munk...@googlegroups.com <munk...@googlegroups.com> on behalf of Dustin Davis <1dusti...@gmail.com>
Sent: Sunday, April 24, 2022 11:08:33 AM
To: munk...@googlegroups.com <munk...@googlegroups.com>
Cc: 'Gregory Neagle' via munki-discuss <munki-...@googlegroups.com>
Subject: Re: [munki-dev] MSC and Notification Center: issues and options
 

Graham Pugh

unread,
Apr 24, 2022, 3:42:18 PM4/24/22
to munk...@googlegroups.com
My initial thought: "Munki" might be a name unfamiliar to the end user, but if munki-notifier was renamed "Managed Software Center Notifier", it would be clear what it is, without having to give it the same localised name as the main app.  

Cheers,
Graham
 

Sent from my iPhone

On 24 Apr 2022, at 20:08, Dustin Davis <1dusti...@gmail.com> wrote:



Gregory Neagle

unread,
Apr 24, 2022, 3:44:58 PM4/24/22
to munk...@googlegroups.com
No. The user-visible (“display”) name is “Managed Software Center” or whatever the localized name is for MSC.app. See the screenshot in my original post. 

Sent from my iPhone

On Apr 24, 2022, at 12:42 PM, Graham Pugh <g.r....@gmail.com> wrote:

My initial thought: "Munki" might be a name unfamiliar to the end user, but if munki-notifier was renamed "Managed Software Center Notifier", it would be clear what it is, without having to give it the same localised name as the main app.  

Graham Pugh

unread,
Apr 24, 2022, 5:29:10 PM4/24/22
to munk...@googlegroups.com


No. The user-visible (“display”) name is “Managed Software Center” or whatever the localized name is for MSC.app. See the screenshot in my original post. 

Yes I understood that the current display name of munki-notifier is set to Managed Software Center. But by changing the identifier to com.googlecode.munki.managedsoftwarecenter-notifier and the display name to Managed Software Center Notifier, would that remove all the hacks and also prevent the duplicated entry in system preferences?

Cheers,
Graham



-Greg

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 .

Allister Banks

unread,
Apr 25, 2022, 12:24:05 AM4/25/22
to munk...@googlegroups.com, 'Gregory Neagle' via munki-discuss
I’m appreciative that work can address this, I’m assuming similarly URL/URI handling to launch the app (e.g. with the munki://updates link/protocol) isn’t what you’re looking for, either.
As another data point, I noticed DataJar’s Notifier does not attempt to override sender and terminal-notifier’s README has conflicting text around using the option, so it looks like there’s pain and inconsistency for everyone over the life of the various versions of the associated frameworks. We don’t expect a lot of users to be concerned with a duplicate listing in the pref pane as there’s been the long-standing one for Chrome that we force on.
Allister

Greg Neagle

unread,
Apr 25, 2022, 4:02:14 PM4/25/22
to munki-dev, 'Gregory Neagle' via munki-discuss
My proposed changes are now in the Munki5dev branch on GitHub, and here is an installer package for testing:


Remember that you’ll be prompted to allow “Managed Software Center” to deliver notifications unless you install a Notification Settings configuration profile pre-approving “com.googlecode.munki.munki-notifier”.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

Greg Neagle

unread,
Apr 25, 2022, 5:24:53 PM4/25/22
to munki-...@googlegroups.com, munki-dev
If you want to trigger a test MSC notification:

sudo defaults write /Library/Preferences/ManagedInstalls OldestUpdateDays -int 1
sudo defaults write /Library/Preferences/ManagedInstalls PendingUpdateCount -int 1
open -a /Applications/Managed\ Software\ Center.app/Contents/Resources/munki-notifier.app

You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/272DA09D-6E64-4F4A-9688-BF8FABA67E1F%40mac.com.

Daniel Moore

unread,
Apr 26, 2022, 4:49:27 PM4/26/22
to munk...@googlegroups.com, 'Gregory Neagle' via munki-discuss
Hi Greg,

I sign and notarize Munki for distribution in my company and I've consistently seen the notification issue you are addressing. Your pre-built pkg works perfectly, but I'm unable to build a pkg on my own from the latest Munki5dev branch. There's a clang failure during installation of pyobjc-core. I'm using Xcode 13.3.1 with Apple clang version 13.1.6 on macOS 12.3.1 on Intel. What versions of Xcode and clang are you using?

Thanks,

Daniel

Greg Neagle

unread,
Apr 26, 2022, 6:15:54 PM4/26/22
to 'Gregory Neagle' via munki-discuss, munki-dev
Xcode 13.2.1 on Apple silicon. I and others have seen issues building PyObjC with Xcode 13.3; unfortunate to hear the problem continues with Xcode 13.3.1. :-(

-Greg

You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/CACOmFV17BT%2BgLtLjVxNz3%3DsU8pneLsQA0GZAQ3H3Mk-GJdwwcg%40mail.gmail.com.

Reply all
Reply to author
Forward
0 new messages