I think you should check if the binary resulting from all this process still counts as being notarized according to Apple, because the EDEN signature may alter the binary itself to embed its signature, and in the eyes of Apple that may become a different binary that’s not notarized.
I haven’t had to code sign using PACE for sometime but I suggest you double check the documentation. From what I remember when you code sign using the PACE tools you pass the information required such that PACE will do the apple signing stuff for you. Also when notarising you should normally aim to notarise the actual thing you will deliver to the customer such as a pkg or dmg. Again PACE may very well cover some additional information about notarisation in the documentation.
So far this is the best solution for notarizing on this forum. One snag I ran into on my machine… for --password I needed to add @keychain:APP_SPECIFIC (note APP_SPECIFIC is what I named my password inside the keychain app, your name may be different).
Also I did receive an Your Apple ID account is attached to other providers. You will need to specify which provider you intend to submit content to. Please contact us if you have questions or need help. (1627) message.
To solve this specify --asc-provider "XXXXXXXXXX" when notarizing.
Now just waiting… No errors uploading... and a RequestUUID
Great, glad it could be helpful! Yes, for password I just put my app specific password directly in there. I’ll try adding it to the keychain to simplify the method, thanks.
No idea what that other message is about, glad you could get it to work though!
Thanks for the easy to read details! Does this mean I don’t have to notarize my plugins if they are distributed inside a pkg? Only the installer needs to be notarized and then the plugins work 100% on Catalina when using the installer?
If you notarize the pkg installer it will notarize all the components contained within it. So they do have to be notasrized it’s just that it’s reduced to a single step.
the automatic signing of xcode doesn’t work anymore. I had to add the --force option when manually signing to be sure the signatures are replaced, otherwise the notarization fails
codesign --force -s "DEVELOPER ID APPLICATION: YOURCOMPANY (CODE)" "FILEPATH.COMPONENT" --timestamp
@lalala I had to sign something for the the first time since you posted that today. Interestingly my original method is still working for me without “–force”. We must be doing something different somewhere!
Could it be that you haven’t set the “Development Team ID” in Projucer (in the xcode options)?
(in which case xcode would not do a first signing before we do it manually)
Hi, Have you figured out how to solve the problem?
We run into the same problem. i.e., we use PACE to wrap our binaries, and then use the command below to code-sign it:
codesign --deep --force --options runtime --sign [Developer ID Application] [file path]
then run the signed app or load the signed vst from AudioPluginHost, it will crash and report “Invalid Signature”.
If we don’t manually code-sign the binaries since PACE wrapper will code-sign the binaries anyway, then notarizing process will fail because the binaries are not signed with “runtime” option turned on.
You can sign with the hardened runtime with the PACE tool by adding the --dsigharden command line option.
And make use of --extrasigningoptions if you have to specify other options to the “codesign” invocation that the PACE tool does internally (perhaps to add an entitlements file with --entitlements)
Sorry for the succint explaination, but we’re in NDA territory here. Use the above as hints to look the details in the help for the PACE tool
Thank you very much for you info. I tried “–extrasigningoptions”, but it seems that wraptool has some builtin options turned on which can override the extra signing options.
When I execute the wraptool command, it shows a message like:
Using this codesign command:
/usr/bin/codesign --force --sign [Developer ID Application: ] -vvv --deep --strict --timestamp --no-strict /tmp/af4dc140-b8a0-4663-a367-5f3e0dbc902b/ProductName_Unwrapped_wrapped.vst
Here “-vvv --deep --strict --timestamp” are the extra options, but still there is a “–no-strict” option at the end.
Hi Matthieu,
yes i got that to. it turned out that i used the wrong context for spctl checking a dmg. have you tried: spctl -a -t open --context context:primary-signature -v /path_to_your/disk.dmg ?
I think my issue is that I probably didn’t sign the dmg. So instead, I’ll just ship the pkg, no reason not to, as it’s properly notarized and everything.