"Application damaged and can't be opened' error prompt on 15.6.1 Sequoia

Yes, that is correct.

OK. That certainly does raise a world of possibilities. The approach I usually recommend for incremental Apple installers is to copy the app and then update the copy. See this post. However, I don’t think that’s feasible for an installer package, and I’m not 100% sure what the best option here is.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello Quinn, a couple of follow up questions on this issue.

My application currently requires elevated privileges or “sudo” to verify the codesign using the codesign —verify --strict command. Will this cause the Apple Gatekeeper to throw this prompt?

If that is the case, why is this prompt not shown on all of the macOS machines if Gatekeeper is unable to read our application due to restricted permissions?

My application currently requires elevated privileges or “sudo” to verify the codesign …

Lemme see if I understand this correctly:

1. You take a Mac that’s never seen your app before.

2. You install your app in the standard way that a user would install it.

3. This command fails:

   % codesign --verify --deep --strict /path/to/your.app
   

4. Instead you have to do this:

   % sudo codesign --verify --deep --strict /path/to/your.app
   

Is that right?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1. Yes, also on Mac where my application is seen earlier

2. Yes, I perform install using "sudo installer" command which is a standard way of installation

3. Yes, that's correct.

Some more information:

Running "codesign --verify --deep --strict /path/to/your.app" throws the following error,

invalid resource directory (directory or signature have been modified)

If I run "sudo codesign --verify --deep --strict /path/to/your.app", it does not throw any error.

I have verified the sudo command run with the verbose option, it says "valid on disk" and "satisfies its Designated Requirement"

Interesting.

In general it’s a bad idea to run code-signing operations as root. And I don’t think this is an exception to that rule. The system should be able to verify your app’s code signature without escalating privileges, and the fact that it can’t could be a source of weird errors.

Is your app is a world-readable directory? Like /Applications? And is the app bundle, and anything nested within it, world readable?

If my Unix-Fu is up to speed, I think this will find any items that are not world readable:

% find /path/to/your.app -not -perm -004 -print

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, my application gets installed in the /Applications/ directory. The contents nested in the application bundle are not world readable.

Would this cause issues like the prompt we have noticed?

The contents nested in the application bundle are not world readable.

Yeah, don’t do that. macOS expects apps to be world readable so that all users can run them, and not following that convention takes you well off the beaten path. Honestly, I’m surprised that this is the first problem you hit O-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"