Question/suggestion about Munkitools installer

[John Lockwood]

As I am sure everyone here especially Greg Neagle :) are aware, newer versions of macOS display an ever increasing number of nag/notification messages.

One more recent category of such messages is an alert if an installer has added a launch daemon, launch agent or login item.

As usual from a security perspective Apple are right to add this although the (vast) number of all these various warnings etc. is becoming wearisome to veteran Mac users.

See - https://www.youtube.com/watch?v=q-U0seSJlFw

Oh the irony!

Anyway - the main point of this post is that whilst it is 'correct' behaviour that such warnings should be shown when an installer does install what are generically referred to as a login items, I have observed the following with regards to installing Munkitools.

1. Multiple login items are flagged after installing MunkiTools (six if I remember correctly) again arguably correct behaviour
   
2. Whenever an update for Munkitools is installed a new set of these alerts are displayed - arguably incorrect behaviour 
   

Specifically regarding issue 2 above. If the update to Munkitools is installing new binaries clearly that has to take place, but 99% or more of the time the corresponding launch daemons or launch agents have not changed and there is therefore no need to reinstall them. Apple is displaying an alert each time it sees such an install and does not check to see if the contents before and after have changed. A warning when overwriting an existing entry is needed incase this is used by malware to replace a valid entry with a malicious entry.

As someone who also builds installer packages I can certainly see that always reinstalling them is by far a simpler process and always ensures the right ones are present but in theory extra logic could be added to the install process to only do this if needed.

Now that Apple are relentlessly nagging us to death each time this happens, this is making it arguably more desirable to be more efficient regarding the install process so as to avoid triggering these notifications.

So Greg, any change of an improvement here? As the content in this case does not I believe have any version label a hash value of the file would seem the logical approach. Since Munki already does hashes perhaps some of this work is already done in Munki. Otherwise it would have to be done in the installer package logic itself.

Note: I have AutoPkg download and add updated Munkitools installers to Munki and then Munki distributes the new version to all user Macs. Therefore hypothetically I could in my override recipe add entries to disable installing the launch daemons but this would be an all or nothing solution rather than actually checking if an install needs to be done.

[Per Olofsson]

27 apr. 2023 kl. 14:35 skrev John Lockwood <jeloc...@gmail.com>:

Note: I have AutoPkg download and add updated Munkitools installers to Munki and then Munki distributes the new version to all user Macs. Therefore hypothetically I could in my override recipe add entries to disable installing the launch daemons but this would be an all or nothing solution rather than actually checking if an install needs to be done.

If you're using AutoPkg to import munkitools, this should already be solved. The munkitools*.munki recipes split munkitools into its component packages on import:

munkitools_admin

munkitools_app

munkitools_app_usage

munkitools_core

munkitools_launchd

munkitools_python

Each has its own version number and munki should only install a component when the component is updated. munkitools_launchd is at version 3.0.3265 and hasn't been changed in a very long time, so at least here it only gets installed once during initial deployment.

Is this not the behavior you're seeing?

--
Per Olofsson, IT-service, University of Gothenburg

[John Lockwood]

@Per

Yes AutoPkg has split it in to those six separate installers - hence six notifications being shown after they are installed.

The April update issued this month did seem to trigger a second set of notifications, I will double check the versions to see if the munkitools_launchd was flagged as a new one. It maybe that I was seeing five notifications and not paying close attention I assumed all six had been flagged again.

[Per Olofsson]

I think the best you can do is condense the notifications into a single one by deploying the appropriate MDM profile, or, if you're so inclined, you can silence the notifications completely by blocking com.apple.btmnotificationagent. Unfortunately the new API Apple is telling us to use, which could potentially be less noisy, doesn't work yet for tools like munki. Hopefully macOS 14 brings improvements on that front.

By the way, have you switched over to the new signed munki builds? I think they change the launch item attribution and possibly also notification frequency.

--
Per Olofsson, IT-service, University of Gothenburg

--
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/97ea649f-4e8e-453d-87e8-167e35ea1fa8n%40googlegroups.com.

[John Lockwood]

Thanks for the heads up regarding a signed version of munkitools. I have just reconfigured my setup to disable the unsigned recipe and switch to the signed one. As currently my repo already has the latest unsigned version it did not add the signed versions. I could delete that version so it will replace them but I will wait till the next release and see what happens.

Regarding the mobileconfig, do you have a link to an article describing what is involved?

[Mike Solin]

This should do it:

https://n8felton.wordpress.com/2022/10/24/login-and-background-item-management-in-macos-ventura-13/

Mike

--

https://mikesolin.com

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/d6d593b2-53db-488d-af5d-03fb35e0a20an%40googlegroups.com.