We are starting to see issues where installing locally via the payload file and postinstall.sh works fine but installing it after being packaged (either via Packages or PKGBUILD) results in the following error when launching the application (Pro Tools 2023.3.0 as an example here)...
' "Pro Tools" is damaged and can't be opened. You should move it to the Bin.'
Following the help icon opens a page stating, "The app has been modified, and its code does not match the original signed code."
In Privacy and Security we can go ahead and choose to "Open Anyway" but this is not a viable way forwards for applications that we are trying to deploy hands-off.
It feels like the packaging process is stripping some attributes from the files. I have tried to use xattr to re-add "Date Downloaded" data but that doesn't resolve the issue.
In the case of our Pro Tools 2023.3.0 package, it copies a DMG to /tmp (we've tried other areas in case this was the problem and we're trying this way due to the problems we've encountered), mounts it and runs the following command...
installer -verboseR -pkg "/Volumes/Pro Tools/Install Pro Tools 2023.3.0.pkg" -target /
Which confuses me, in this instance, why it's creating a problem as, even if any attributes are being stripped from the DMG, it shouldn't affect the PKG inside it, should it?
I've seen a similar thread where someone said (about another app) "just use the App Store version" which isn't a fix for all packages, obviously, and we're looking for a general fix for this issue.
Any help would be gratefully received as this has us really stumped...
Is it just Pro Tools that you are having issues with, or is it any package you are building?
The error you are seeing usually comes from the notarization being broken on the files. JAMF would install the package fine but when you launch the application gatekeeper will eat it as the notarization is broken. You should very rarely need to use xattr for anything if everything is being done correctly.
I found the article below while researching the issue. It looks like Ventura's security can be a bit overzealous when apps are modified. From my experience it looks like any app that has a helper tool that provides updates could be subject to this gatekeeper block. In my case, the jamf framework update seems to be causing this.
I also noticed that some people on reddit found a workaround. The article above explains why this workaround works.
@bwoods, although it's a similar issue I don't think the root cause is the same. Effectively this isn't really a Jamf issue as we're getting the error before even passing the package through Jamf, more just a general packaging error.
@AJPinto, I'm sure we have seen it with other apps but sadly I don't have specifics at this time. I'm just trying to get my head around why this problem is occurring at all.
Running the install script manually in terminal against the source files results in a working app, packaging it up breaks something - possibly the notarization. Any idea how we would check files before after packaging to see if something has changed? I suppose we could perform a basic CRC check to compare the main DMG before / after package build. But then, if that's the problem, any idea how we would rectify it? I presumed bundling the original DMG into a new package might just fix it, but obviously it doesn't.
CRC of the DMG hasn't changed pre / post-packaging...
Extracted as part of the re-packaged installation...
Is this evidence enough of the file not being changed / notarization not being removed?
@bwoods, OK, Jamf is not the problem but the fix from your first post was to re-install the Jamf framework, so, yes, Gatekeeper is the thing that is triggering the "fault" but re-deploying the app, in this case, isn't a fix.
Adding the app to the developer tools doesn't work for this case either.
Gatekeeper isn't really at fault (as far as I know), it's doing what it's designed to do but we have to work within the confines that Apple create and understanding why installing a package one way is OK for Gatekeeper but not via another is going to be key for us rolling out other problematic packages going forward.
@Stuart_P , Jamf isn't the only app that I'm seeing this issue for. It's any app that's modified, updated, upgrade..etc. Jamf is just the most important app. All I'm saying is to take a look at this article. It's dense but it explains what's happening. How macOS Ventura App Management works and doesn't work (lapcatsoftware.com). For instance, notice how the screenshot below isn't the Jamf.app.
There are also admins on reddit saying that it's happening for other apps as well. Just pointing out the connections. If you´re receiving a message saying your app is damaged and can not be opened in Mac OS Ventura, th...
I have received a few reports as of 13.3.1 with people getting some notarization errors with some random applications. Updating the applications usually fixes the issue, or let us clear quarantine. We all know apple, they will say these applications should have been tested in beta and updated before the OS update released (never mind 13.3.1 was did not have a beta). The problem is never Apples fault... ... ... (sarcasm)
So having read the posts and whether or not Gatekeeper is at fault or if it's doing what it's supposed to (and acknowledging that people are undeniably having issues with Gatekeeper)...
Installing the app directly from the script has a different outcome to installing it from the re-packaged custom package which doesn't relate to the information provided. In theory, why would these provide a different outcome in the app's interaction with Gatekeeper?
I'm not here to bash Gatekeeper and I acknowledge the broad dislike for it and the problems it poses but I'm really struggling to get my head around why re-packaging the app has any bearing on its interaction with it, especially when the CRC of the DMG isn't changing before / after being re-packaged. So, fundamentally, what happens when you install an app from a re-packaged .pkg when compared to just running the install script manually against the source files?
@AJPinto, I get the fact that updating apps / re-installing is generally the fix but, in this scenario, it's the same app, just being installed in two different (but as near identical as can be) ways and re-installing is not a solution in this case. As above, I'm looking to understand the differences in the two ways of installing the product that might be feeding into the "problem"?
But our package copies the DMG, then scripts mount it and uses "install" on the PKG inside it to install the .app. Our package has done its job so it's not being blocked itself. I'm not dismissing the possibility that Gatekeeper has somehow linked our package identifier to the final .app we're trying to run but where would we see this relation (if it exists) in order to trouble-shoot that?
As before, presumably when being deployed by the re-packaged PKG it feels like maybe it's somehow getting linked to the fact that we're not signing the packages with a dev cert and that app has been placed there as part of that process - but how would we confirm that?
Also, if that were the case then presumably this would affect all our packages, and that's not the case.
Ah, you should definitely sign your packages if you have gatekeeper on. My issue is that gatekeeper is off and I'm getting this prompt. Seems like a bug to me. Nothing you can do about it unfortunately until Apple does something. Thanks for testing.
I suppose the issue I have is that our scripts aren't touching the app after it's deployed and the sig seems to be fine on the .app but it's just hard to try and understand the chain of events that leads one way to deploy it leaving it broken.
We have, just now, worked around this (and it might feed into future work-flows) by adding the PKG directly from Avid into Jamf (without re-packaging it and bundling the pre and post scripts directly) and adding a pre and post script into the policy itself. Doing this means we lose a bit of error handling within our standard install script but it works and seems to be a way forward.