Notarisation invalidated with Drag & Drop or Copy & Paste in Finder

The error you’re seeing, a sealed resource is missing or invalid, is unrelated to notarisation. Rather, it’s coming from the code signing subsystem, telling your that something has broken the seal on the app’s code signature.

It’s hard to say exactly how this has come about but it’s definitely something specific about the way your app is structured. You wrote:

Is there a way to copy MyProg.app out of the enlocing DMG and keep the notarisation without resorting to command line?

That’s what happens with every other app I’ve ever seen (-: For example, I downloaded the disk image for Hex Fiend, copied the app out using the Finder, ran your command [1], and I got this:

% spctl --ignore-cache --assess -vvvv "Hex Fiend.app"
Hex Fiend.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Kevin Wojniak (QK92QP33YN)

The most common cause of problems like this is that the app’s bundle isn’t structured according to the rules in Posting a Crash Report. I’ve seen some very mysterious problems result from non-standard bundle structures. However, the specific symptoms you’ve described are not something I’ve seen before.

If you replicate the problem and then do this:

% codesign -d -vvv --deep --strict MyProg.app

what do you get?

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

[1] To be clear, this isn’t the way I recommend that you test notarisation — rather, I recommend that you use the techniques discussed in Testing a Notarised Product — but I thought it important to replicate your process closely.

Hello Quinn,

Here is the result of the codesign command in the BAD case (i.e. the .app copied out of the DMG container):

And now also how it looks like in the good case, when the .app is still in the DMG container:

The two files are identical - no differences.

HOWEVER: further examination has revealed, that the output of "ls -alR" does show some differences depending on whether the copy was done in finder or on command line! I think the difference that might be of relevance considers "non-ascii" characters in file names. Here is what I mean (reduced to the part of the "ls -alR" output that is showing the difference - only actually visible in HEX). Can that be important?

Sorry, wrong files attached, and I don't see how I could edit the post! Here are the correct ones you requested:

Earlier I wrote:

The most common cause of problems like this is that the app’s bundle isn’t structured according to the rules in Posting a Crash Report.

D’oh! Wrong hot key. That was link was meant to be to Placing Content in a Bundle.

You wrote:

Here are the correct ones you requested:

Thanks. Sadly, I asked for the wrong info here. What I actually need is the output from:

% codesign -v -vvv --deep --strict MyProg.app

Clearly I shouldn’t be answering DevForums questions after 23:00 )-:

However, I think you’ve already found the issue here:

"non-ascii" characters in file names … Can that be important?

Yes. This is a known issue with code signing (r. 68829319). In Unicode many characters can be rendered in different ways. For example, an Á (A acute) can be encoded either precomposed, as U+00C1 (LATIN CAPITAL LETTER A WITH ACUTE), or decomposed, as U+0041 U+0301 (LATIN CAPITAL LETTER A followed by a COMBINING ACUTE ACCENT). If copying the files changes this rendering, it breaks the code signature.

On HFS Plus this was rarely a problem because all file names were canonically normalised. However, APFS is normalisation preserving [1], which means that the rendering of your file names can vary based on how you copy them. That’s why a Finder copy breaks the code signature but ditto does not.

Ultimately this is Apple’s bug to fix but, right now, the only good solution is to stick to ASCII file names within your bundle.

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

[1] It’s also normalisation insensitive but that only goes so far. The way that code signing uses the file system means that this normalisation insensitivity doesn’t help it.

Quinn,

man, you're the absolutely best! Thanks - this is indeed what was wrong! After copying the correct files over the "faulty" ones, the problem was gone. The "codesign -v -vvv...", as you suggested, even told me exactly which files were problematic. All of them had non-ascii characters in their file names!

Another mystery solved. :)

Cheers, alex.