Checking DMG notarization. Rejected, but works fine

The notary service does not require that your disk image be signed. If the disk image is signed then it’ll include the image itself in the ticket (along with all the image’s content). If not, the ticket is built just from the image’s content.

Having said that, I do recommend that you sign your disk image. See Signing a Mac Product For Distribution for my advice on that front.

I checked other downloaded apps (Intel or Universal). Some DMG files
pass DMG notarization … and some fails

You are not checking notarisation here, you’re checking Gatekeeper compliance. And spctl is a poor way to check for that. See Testing a Notarised Product for my advice on how to do that.

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

Quinn,

Thanks for your reply and advices!

1. I added codesign for a DMG image. And then spctl shows that DMG is correct:

Code Block 
MyApp.dmg: accepted
source=Notarized Developer ID

It seems that many Mac developers (including me) were not aware that it also necessary to codesign DMG in addition to codesigning of APP bundle and notarization.

2. Probably I found a typo in your article "Testing a Notarised Product". It says:

Code Block 
# Disk image
spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg

However this command shows nothing for any correctly notarized app (including my app, Chrome, Audacity, etc).

If I add "-v" to your command:

Code Block 
spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg -v

It shows a result for Chrome:

Code Block 
googlechrome.dmg: accepted
source=Notarized Developer ID

Another question. I build a special ZIP with APP bundle for Auto Update feature. This ZIP is being notarized.

How I can check that APP bundle is notarized and a difference with only codesigned APP bundle?

Code Block 
spctl -a -t exec -vvv MyApp.app

always shows the same result for codesigned APP, regardless notarization:

Code Block 
MyApp.app/: accepted
source=Notarized Developer ID
origin=Developer ID Application: COMPANY (RDPXXXXXX)

Sometimes codesign for a DMG doesn't work correctly:

Code Block 
codesign -s "Developer ID Application: COMPANY" --timestamp -i MyApp MyApp.dmg

I got an error:

Code Block 
"The timestamp service is not available."

and DMG was not completely signed. APP bundle was signed correctly (a minute earlier) and notarized (several minutes later).

I re-launched the script again and next time DMG was signed rightly.

it also necessary to codesign DMG in addition to codesigning of APP
bundle and notarization.

It isn’t necessary to sign disk images. As I mentioned above, the notary service will accept an unsigned disk image and the resulting ticket will then cover just the disk image’s content.

Probably I found a typo in your article "Testing a Notarised Product".

The command works on my machine. Specifically, I just downloaded the latest Chrome disk image and here’s what I see:

Code Block  
% sw_vers
ProductName:	macOS
ProductVersion:	11.2.1
BuildVersion:	20D74
% spctl -a -t open -vvv --context context:primary-signature googlechrome.dmg 
googlechrome.dmg: accepted
source=Notarized Developer ID
origin=Developer ID Application: Google, Inc. (EQHXZ8M8AV)

---

always shows the same result for codesigned APP, regardless notarization

Can you post more details about the exact workflow you’re using here?

Keep in mind that notarised tickets identify code via the cdhash. So, imagine a sequence like this:

1. Build your app.

2. Create a disk from the app in step 1.

3. Notarise that disk image.

4. Check its notarisation.

5. Create a ‘software update’ zip archive from the app in step 1.

6. Check its notarisation with spctl.

The check in step 6 will always succeed because the check in step 4 has caused your system to ingest a ticket that covers the app’s cdhash.

This is exactly the sort of thing that taught me to always test this stuff in a VM, where I can roll back the VM to a snapshot that’s never seen my software before.

---

The timestamp service is not available.

This means that codesign is unable to access the Apple timestamp service (timestamp.apple.com). I’ve seen two causes of this:

• Network problems on the client side.

• The timestamp service being down )-:

My experience is that the first one is the most common. You should use a packet trace to see what’s going on.

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

Then again, it’s possible that the timestamp service is having problems at the moment.

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

Quinn,

Thanks for your replies!

My workflow is the following:

1. Build my APP

2. Codesign my APP

3. Create a DMG from my APP

4. Notarize DMG...

5. Staple notarization to DMG

6. Create ZIP from APP (from step 1) for Auto-Update

7. Notarize ZIP...

8. Staple notarization to original APP (from step 1)

9. Delete ZIP

10. Create a new ZIP from APP.

Is it correct?


I've understood about timestamp servers.

I tried again a command from your article:

Code Block 
spctl -a -t open -vvv --context context:primary-signature googlechrome.dmg 

and now it works on iMac (Intel) Big Sur 11.2.3. Earlier it didn't work on DTK with Big Sur 11.1.0

It is beyond baffling that there is no simple explanation of the steps that are required. Every explanation in the Apple documentation and in online explanations are fragmented and disjointed and appear to always omit some critical step.

Like "notary tool doesn't require a signed DMG" - well OK but does Gatekeeper not require a signed DMG?

Why does the Apple example of customising the Xcode archive process make no mention of Stapling anything - not in the document nor in the sample script ?

Why is that - is stapling something that is optional - if it is not optional why is it not included in the sample script ?

Similarly the sample script doesn't code sign the DMG file - why not ?

Surely the sample script should produce a DMG file that is ready for distribution ?

Hopefully I am just missing something simple here.

My general advice is that you start with these two docs:

• Creating distribution-signed code for macOS

• Packaging Mac software for distribution

They describe the process as a whole. If you find anything there unclear, I’d be happy to clarify that here.

Coming back to your specific questions:

Like "notary tool doesn't require a signed DMG" - well OK but does Gatekeeper not require a signed DMG?

It does not.

Why does the Apple example of customising the Xcode archive process make no mention of Stapling anything - not in the document nor in the sample script?

That is a weird omission. I suspect that it’s an artefact of history [1]. Regardless, I encourage you to file a bug requesting that we correct that omission.

Please post your bug number, just for the record.

is stapling something that is optional

Stapling is optional, although recommended for the reasons described in Packaging Mac software for distribution. Notarisation Resources has a link to a DevForums post, The Pros and Cons of Stapling, that explains this trade-off in more detail.

Similarly the sample script doesn't code sign the DMG file - why not ?

Probably because it’s not required.

Surely the sample script should produce a DMG file that is ready for distribution?

It does, albeit one that values simplicity of thoroughness. I think it’d be reasonable for you to request a fix for that as part of your bug report.

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

[1] You can’t staple until notarisation is complete, and historically there was no good way to wait for that. That changed when we moved from altool to notarytool. The example in Customizing the Xcode archive process was updated to use the new --wait flag, but not updated for the knock-on effects of that flag.