Signing and notarizing non-standard pkg

I recommend that you use rpath-relative references for this sort of thing. I discuss the basics of this in Embedding nonstandard code structures in a bundle.

Once you do:

• Your app’s won’t have any nested code, so you can just sign the top-level bundle.

• Each framework, dynamic library, plug-in, and helper tool will be a single code item, so you can just sign its as a top-level item.

For general advice on the signing stuff, see:

• Creating Distribution-Signed Code for Mac

• Packaging Mac Software for Distribution

IMPORTANT For this to work, all your apps must have library validation enabled. You can get that by default when you enable the hardened runtime. If you go out of your way to disable library validation, Gatekeeper is going to get grumpy with you.

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

Thank you very much! That sounds like a good plan.

Some more minor follow-up questions:

• Which identifier should I use to sign the libs and command line helper tools in bin? Can it be the same for all? How is this used?
• We also have a share with examples and a documentation folder. I assume this does not have to be signed, right? What about shell scripts? Is there maybe a good script to sign everything that is signable without entitlements and then only (re-)sign manually if any entitlements are needed (I expect that no entitlements will be necessary, at least in our libs/tools)?
• Regarding notarization, I guess uploading the pkg and stapling the ticket will be enough?

Best, J

Which identifier should I use to sign the libs and command line helper tools in bin?

I have specific advice about this in Creating Distribution-Signed Code for Mac. To find it, search for the phrase “If you’re signing non-bundled code”

Can it be the same for all?

Can it be? Yes. Should it be? No.

The code signing identifier should be unique to each conceptually separate code item.

How is this used?

It forms part of the designated requirement, which is used by various system services, like the keychain, to uniquely identify the code. I go into this in gory detail in TN3127 Inside Code Signing: Requirements.

We also have a share with examples and a documentation folder. I assume this does not have to be signed, right?

Right. Presuming that these are outside of any bundled code item.

Well, technically, they will be sealed by the code signature of the overall installer package you’re creating, but you don’t need to do anything special to cover that.

What about shell scripts?

That depends on where you place them. If they are outside of any bundled code item, they don’t need to be signed. If they are inside a bundled code item, sign them as data. I explicitly called out the second point in Placing Content in a Bundle.

Is there maybe a good script to sign everything … ?

That’s called Xcode (-:

Seriously though, Xcode handles a huge array of signing and distribution issues. If you choose not to use it, or your building a product that’s not covered by Xcode’s distribution mechanism, Apple assumes that you’ll build your own automation tools.

Regarding notarization, I guess uploading the pkg and stapling the ticket will be enough?

Yes.

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