I have figured out what my problem was here. The reason for the error from:security set-key-partition-list was that the certificate did not include a private key. As for how to use security to export a certificate: in my case the answer is don't. Use openssl to generate the .p12 certificate file: openssl pkcs12 -export -out afile.p12 -inkey privte.key -in certificate.pem

I have decided to get around this problem by going with the flow and changing my CFBundleVersion to a simple integer value.

I have the same problem. Did you find the cause?

As mentioned in this thread The typeIdentifier for the root container must be set but it must also be writable or the files app will not be able to copy files into your container even if sub folders are writable.

To answer my own question it looks like the solution is to always use NSString stringByResolvingSymlinksInPath to resolve any symbolic links before trying to compare paths. My '_myRoot' contained a symbolic link because the path to the shared group folder returned by [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier: group_id] contains symbolic links.

I am not sure why it should be OK to skip signing the frameworks because they have already been signed but not to skip signing the other parts of the bundle even though they have also already been signed.Code signing on OS X is definitely a ***** which tends to bite you if you poke it. I wish someone could tame it.

Thanks for your reply but I think I have found out how to get this to work.(If the app were small I would not bother with this but it contains a lot of resources and code signing can take a bit of time.)The trick is that you need to reseal the app after updating and signing the resource. From my experiments the app seems to be sealed and the "_CodeSignature/CodeResources" file created when the bundles exactable is signed.So the following works after updating the file "myapp.app/Contents/Resources/CustomFile":codesign -f --s "Developer ID Application: MY Company" --options runtime --keychain "Buildsystem" "myapp.app/Contents/Resources/CustomFile"codesign -f -s "Developer ID Application: MY Company" --options runtime --keychain "Buildsystem" "myapp.app/Contents/MacOS/myapp"Note the '-f' option to force the resigning.If there is a better way to reseal the app maybe someone can tell me I couldn't find any documentation saying what triggers the sealing of the app.If what I am doing is 'bad' then maybe someone can tell me why I shouldn't do this.

Thanks for the reply,Yes that would make the hole in the security smaller but it still wouldn't prevent an installer from placing an infected file onto the machine that would do something nasty when opened by a trusted app.Making something secure while allowing it to still be usable is not easy. 🙂

Thanks for the explanation.Doesn't that mean that so long as the user installs our app using the notarized installer then the app itself doesn't need to be notarized since it will not be marked as quarantined? (Assuming they do not try to distribute the unpacked app itself over the network.)This kind of points to a hole in the security provided by notarization and the gatekeeper. An evil person can wrap their virus infected app in an installer which hides the virus and have the installer notarized so that the actual virus is installed undetected.The only way to protect against this would be to mark anything created by a quarantined app as quarantined.

Thanks for the reply,What you suggest is what I thought I may need to do which requires our automated build process to upload 2 separate packages to Apple and wait on each of them to be notarized before completing the build. Depending on how fast the network is and how long the notarization takes it will add a significant amount of time to the build process. Our build process builds a lot of different apps so this is painful.We may consider using a standard installer.The thing that still puzzles me is why the gatekeeper doesn't complain about the un notarized app when it starts. Any ideas as to why that may be?

It is a custom installer format.

I realize now that "xcrun altool --notarize-app" just uploads the app for notarization so the fact that it has succeeded doesn't mean the app was notarized.So it is probably not feasable for the build script to staple the notarization to the installer since it could take some time before you know if it worked or not.