Packaged App reports, ' "APPLICATION" is damaged and can't be opened...'

[Stuart_P]

Hi,

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...

Thanks

Stuart

[AJPinto]

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. 

[bwoods]

@Stuart_P , I've been having similar issues since upgrading to Ventura. see my post here: Re: Jamf.app is damaged and cannot be opened - Jamf Nation Community - 287995

[bwoods]

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.

How macOS Ventura App Management works and doesn't work (lapcatsoftware.com)

[bwoods]

I also noticed that some people on reddit found a workaround. The article above explains why this workaround works.

If you´re receiving a message saying your app is damaged and can not be opened in Mac OS Ventura, th...

[Stuart_P]

@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.

[bwoods]

@Stuart_P , I'm not saying that it's a jamf issue. It's an issue with gatekeeper in Ventrua.

[Stuart_P]

CRC of the DMG hasn't changed pre / post-packaging...

Pre-packaged version...
crc32 /Users/default/Desktop/ProTools2023.3.0_PKGBUILD/root/Pro_Tools_2023.3.0_Mac.dmg
12e2720c

Extracted as part of the re-packaged installation...
crc32 /tmp/Pro_Tools_2023.3.0_Mac.dmg
12e2720c

Is this evidence enough of the file not being changed / notarization not being removed?

[Stuart_P]

@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.

[bwoods]

@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...

[bwoods]

deleted

[AJPinto]

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) 

[Stuart_P]

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"?

[bwoods]

@Stuart_P  gatekeeper is likely classifying your custom package as a malicious attacker attempting to modify apps. Gatekeeper is just buggy in my opinion. All I can do is report this in apple seed and hope that Apple fixes it.

[Stuart_P]

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?

[bwoods]

@Stuart_P , I want you to do a simple test for me. Make that pop-up appear again then navigate to System Settings> Privacy & Security >scroll down to the section in my picture below and tell me what you see.

[Stuart_P]

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.

[bwoods]

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.

[bwoods]

I found this link as well. It looks in line with your issue. Installing apps from unidentified/unsigned developers on macOS Mojave : osx (reddit.com)

[Stuart_P]

I was going to say...  the next step for trouble-shooting at my end is probably to get an Apple Dev account setup (I think I probably have one from many years ago) and get a cert setup for this to see if it makes any difference.

[bwoods]

@Stuart_P , one more thing. Could you submit a report of this issue at the link below. I can't use apple seed since 13.3.1 is not in beta. I'm also filling out a report for my issue as well. We just need to stay on their heads.

https://support.apple.com/en-us/HT201220

[bwoods]

This guy basically sums this up for me. It looks like admins and vendors need to bend to Apple's will. (Unfortunately)

[bwoods]

[Stuart_P]

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.

[_CJ]

---

@Stuart_P wrote:

Installing the app directly from the script has a different outcome to installing it from the re-packaged custom package

---

You put that perfectly, because I have the same workflow and am running into the same problem.  I'll give your suggestion of adding the PKG directly into my Jamf distribution point a try, but man that stinks.  

Is there a clear reason why the repackaged installer thing doesn't work?  It does seem to be a Gatekeeper thing based on the unified logs, but I'm a little unsure what kind of Gatekeeper policy changed that is resulting in this behavior.  Something about... a PKG script invoking /usr/sbin/installer to install another PKG file? 

In my case, both the container PKG (the one I built) is signed with an Apple Dev certificate, as is the PKG that is being invoked is signed by Avid.

Since all PKGs are known and trusted, I feel one should be able to approve these kinds of situations that Gatekeeper would (now) normally block.

[Stuart_P]

Is there a clear reason?  To me, no.  It's also strange that this only happens to a sub-set of applications / vendors and there's seemingly no way to predict it.

[tomtunney]

i have found a similar issue with "waves central" that is downloaded and copied to applications from the dmg using the cp -rf command in ventura.   the file size and date in the off the app is changing between the dmg and the applications folder.  however if i manually drag and drop it the size and date are retained.

[tomtunney]

 

[tomtunney]

Hey Stuart.

What command are you using to copy the installer from the dmg?

[Stuart_P]

I imagine it was a very straight-forward "cp -Rf /Source /Destination"

However, I would, very much imagine that what you're seeing is expected as the DMG will compress the contained data.

[tomtunney]

what ours was missing was the cp -Rfp once we added the p everything worked

[Stuart_P]

That's worth knowing.  I think I've got Pro Tools to look at tomorrow so it might be a good chance to give it a try.