I am working on creating some installer packages to run on some Macs that are not yet enrolled in my Jamf Pro server. For reasons outside my control, we need to install several apps on these Macs using the processes that would have ran had they been enrolled in Jamf Pro. The installer packages deploy all the install components, then they use a post install script to finish the install process. The post install scripts feed in tokens and licensing information. I am using a valid Apple Developer ID installer certificate. If I launch any of these packages, I can see that the certificate is there. I can also open them in Suspicious Package. It shows that the certificate is there and trusted. When I launch these packages on a Mac that is not the one I used to create them, I see this error: "Apple could not verify “NameOfMyPackage.pkg” is free of malware that may harm your Mac or compromise your privacy." I can run "sudo xattr -r -d com.apple.quarantine" followed by the path to the package. It will open properly after that. The people who are going to run these packages have several hundred Macs to run them on. I would prefer not to have to make them run that command for every package. I am using Composer to create these packages and I am signing them with a valid Developer ID Installer package. What else do I need to do to make these installers work right?
Getting error "Apple could not verify “CustomInstaller.pkg” is free of malware..." error.
+23
+25@howie_isaacks Have you checked the clock on the Macs reporting the error? If the clock is off the developer cert might not be considered valid.
+7We should lower the default security level of macOS, but this will necessarily require running a script since they aren't enrolled in Jamf.
Why not enroll them?
+26You are dealing with gatekeeper, and it is not happy due to something not being notarized correctly. Packages deploy from Jamf Pro are automatically signed, so that will not be the problem. My bet is something that you are packaging is not notarized correctly.
Running xattr is just whitlisting the binary so gatekeeper does not block it, this can be done with a script, but ideally you want to actually fix the issue and notarize the binaries.
https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution
+23We should lower the default security level of macOS, but this will necessarily require running a script since they aren't enrolled in Jamf.
Why not enroll them?
The reason why I can't enroll them is because of our enrollment customization that requires users to login using their AD credentials at the time of enrollment. The users of these Macs do not yet have accounts in our AD.
+23I appreciate the responses! I was using AirDrop to move the packages from my Mac where I built the packages to the test Mac. It turns out that doing this makes the packages appear suspicious. When I copied them over using a USB-C drive and also uploaded them to OneDrive for someone else to test opening on their Mac, they worked. I don't remember seeing this as an issue in the past but using AirDrop appears to have been the cause of my issue. I was also testing with a Mac VM. The VM didn't have this issue. I was moving the packages over using file sharing.
+25I appreciate the responses! I was using AirDrop to move the packages from my Mac where I built the packages to the test Mac. It turns out that doing this makes the packages appear suspicious. When I copied them over using a USB-C drive and also uploaded them to OneDrive for someone else to test opening on their Mac, they worked. I don't remember seeing this as an issue in the past but using AirDrop appears to have been the cause of my issue. I was also testing with a Mac VM. The VM didn't have this issue. I was moving the packages over using file sharing.
Good catch @howie_isaacks , thanks for sharing what triggered the problem.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.