Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

App notarization and how it affects a fleet

So I read this article yesterday from Apple: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

I was left with a large handful of questions that some folks here may know the answer to. I'll break down my questions by what types of non-Mac App Store installer packages I have if that helps:

Type 1: Reasonably well-designed vendor installation packages. In that category, I include such titles as Microsoft Office 2019. Right now we mostly import such packages straight into the JSS. With these I presume I will simply need to acquire a new build; however I find myself wondering...what happens if there isn't a newer build available right away.

Type 2: Drag and Drop installers such as Google Chrome, Firefox, VLC and others. These packages were primarily intended for a user to do just that...drag and drop them into the Apps folder. Like most admins here, we likely drop into some sort of packaging utility to place the file where we like set permissions or the like and perhaps add PDFs of support documentation to a given location on the drive. In the case of Firefox, I also I have to inject the policies.json file to the appropriate location. Will I be able to get PKGS that I build containing someone else's stuff properly notarized? Will the vendor see it in the system as a rogue build of their stuff and ask Apple to kill it? Unknown.

Type 3: Reasonably well written packages that include kernel extensions. Basically on these I'm guessing it's mostly the same as Type 1. I can say I'm gonna look like a schmuck if someone's scanner was working on 10.14.4 and all of a sudden if I have to wipe the machine, install 10.14.5 clean, then reinstall the scanner software and watch the driver not function.

Type 4: VERY POORLY WRITTEN VENDOR PACKAGES....in my fleet that would include Corel Painter 2019, Finale v26, the Print Shop (written with a BitRock installer!). I know @donmontalvo has written about some gnarly ones as well. The correct answer perhaps is to get the vendor to fix....yeah that doesn't always happen. That leaves me "repackaging" stuff in these rare cases. The vendor-supplied volume license build of Corel Painter 2019 .pkg fails to even install successfully from the command line. If I run through the GUI and repackage properly, I have found myself to come out okay. Finale v26 is kind similar though it at least installs successfully. With it though, it makes some screwy proprietary processes that install all the stuff for Garritan Personal Orchestra. I have found that repackaging it serves me better. Will I be able to get PKGS that I build containing someone else's stuff properly notarized? Will the vendor see it in the system as a rogue build of their stuff and ask Apple to kill it? Unknown. I personally use Composer, but have used other titles as well like Packages.

I just want to pick people's brain on the subject. I know @rtrouton has a good write up here on notarizing your Automator apps...that helped me with some of what I'm up against: https://derflounder.wordpress.com/2019/04/10/notarizing-automator-applications/

I'm willing to put in the work to get stuff notarized and have a developer account with signing cert, but I want to make sure what I am trying to do is even the right thing.

Like Comment
SOLVED Posted: by ateazzie

HI

I would like to know the same thing as well.
and actually am even more interested in how to restrict 10.14.5 specifically.
In Jamf you can only restrict a proces, but this installer will will probably be seen as install MacOS Mojave

Like

Jamf wants to hear your feedback around Peripherals and Jamf Connect settings configuration