Back to Codesigning, Notarizing and stapling.....

[Lindon]

Okay - spent some more time on the apple dev forums to get this:

When you staple a ticket to a product,

stapler
does the following:
It gets the cdhash from the product. This code directory hash value uniquely identifies the code. You see it for yourself using

codesign -d
.
It asks the Apple servers for a ticket that includes that cdhash. This ticket was generated and stored on the Apple servers when you notarised the product.

It attaches that ticket to your product. The exact mechanism for doing this varies but, for a bundled product like an app, it simply copies the the ticket to

Contents/CodeResources

but also....

So, to clarify, Apple’s general recommendation is that you:
Sign all your code from the inside out, up to and including any signable containers.

Then notarise and staple the outermost container.

Ship that stapled container.

So, for example, if you ship an app inside an installer package on a disk image, you’d sign the app, then the installer package, then the disk image, and then notarise and staple the disk image.

The ticket that you staple to the outermost container will cover any nested containers and code. The system ingests this ticket when you open the outermost container for the first time.

There are exceptions to this rule. Most of them are edge cases that most folks can ignore, but there’s one important one. If you ship an app inside a zip archive, you can’t sign your outermost container because zip archives don’t support signing. In that case you should:
1. Sign the app.

2. Zip that.

3. Notarise that.

4. Take the app from step 1 and staple that.

5. Zip that.

6. Ship the zip archive from step 5.

The system will ingest this ticket when the user first launches the app.

So in truth the answer is "mostly" do the zip , but if that fails then its Ok to do the "app" itself...

[d.healey]

@Lindon I have a situation now where I just want a plugin (vst3 and component) in a zip file, no pkg.

I've codesigned the plugins.
Put them in a zip file.
Uploaded the zip for notarization. All went well.
Unzipped the notarized zip file.
Attempted to staple the files but I get an error rejected (the code is valid but does not seem to be an app)

Any ideas?

[Dan Korneff]

@d-healey I think the zip file is what got notarized, not the contents.

[Dan Korneff]

@d-healey
You can notarize several different types of software deliverables, including:
macOS apps
Non-app bundles, such as kernel extensions
Disk images (UDIF format)
Flat installer packages

It appears to only be for executable files.

"When the user first installs or runs your software, the presence of a ticket (either online or attached to the executable) tells Gatekeeper that Apple notarized the software. Gatekeeper then places descriptive information in the initial launch dialog to help the user make an informed choice about whether to launch the app."

[d.healey]

@Dan-Korneff said in Back to Codesigning, Notarizing and stapling.....:

@d-healey I think the zip file is what got notarized, not the contents.

Yes, but Apple says this

[Dan Korneff]

@d-healey hmmm....

[Lindon]

@d-healey said in Back to Codesigning, Notarizing and stapling.....:

@Lindon I have a situation now where I just want a plugin (vst3 and component) in a zip file, no pkg.

I've codesigned the plugins.
Put them in a zip file.
Uploaded the zip for notarization. All went well.
Unzipped the notarized zip file.
Attempted to staple the files but I get an error rejected (the code is valid but does not seem to be an app)

Any ideas?

nearly right... no need to unzip the notarised zip... just staple the ORIGINAL plugin..from step1. . then zip this up for delivery...

[d.healey]

@Lindon Oh ok, I'll try that, thanks!

[Lindon]

@d-healey Yeah it makes no sense to me on all sorts of levels... but it works...Apple.....

[d.healey]

@Lindon Hmm I just tried it but I get the same message about it not being an app