I got a new macbook pro 13". I got all my files transferred over and read my developer profile into Xcode. I thought all was fine but all my apps were crashing in _libsecinit_setup_secinitd_client. After some checking around I realized that any macos app I create will crash if I turn on App Sandbox. Here are the exact steps:
(1) create new Cocoa Application project in Xcode. Build and run on this works. (2) Enable Development Signing and select my developer account. Build and run on this works. (3) Go to Capabilities and turn on App Sandbox. Build and run and it crashes - see below
http://www.grandinetti.org/resources/appcrash.png
Strange thing is when I switch back to my 2011 Mac Mini (running the same MacOS 10.12.2 (16C67) and Xcode 8.2.1 (8C1002) the project builds and runs with the App Sandbox turned on. So it seems to be related to my MacBook Pro 13" but I cannot seem to find what I'm doing wrong.
Any suggestions?
Thanks,
Philip
p.s. I code as a hobby so apologies for not being fully aware of other investigations I could have done.
1 Answers
Answers 1
You should have read Apple document:
Modern Xcode makes it easy to adopt code signing for your app. You provide your developer program credentials, and Xcode handles most of the rest automatically. For more about code signing, including descriptions of both how it works and how you use it, read Code Signing Guide.
OS X enforces a tie between an app’s container and the app’s code signature. This important security feature ensures that no other sandboxed app can access your container. The mechanism works as follows:
When the system creates a container for an app, it sets an access control list (ACL) on that container. The initial access control entry in that list contains the app’s Designated Requirement (DR), which is part of the app’s signature that describes how future versions of the app can be recognized. See Code Requirements in Code Signing Guide for a description of the DR. Each time an app with the same bundle ID launches, the system checks that the app’s code signature matches the designated requirements specified in one of the entries in the container’s ACL. If the system does not find a match, it prevents the app from launching. OS X’s enforcement of container integrity impacts your development and distribution cycle. This is because, in the course of creating and distributing an app, the app is code signed using various signatures. Here’s how the process works:
Before you create a project, you obtain three code signing certificates from Apple: a development certificate, a distribution certificate, and (optionally) a Developer ID certificate. (To learn how to obtain these code signing certificates, read App Distribution Guide.) When used in conjunction with the corresponding private keys from your keychain, these certificates form three separate digital identities. For development and testing, you sign your app with your development identity. When you submit a version to the app store, you use your distribution identity. If you are distributing a version outside the app store, you use your Developer ID identity.
When the Mac App Store distributes your app, it is signed with an Apple code signature. For testing and debugging, you may want to run both versions of your app: the version you sign and the version Apple signs. But OS X sees the Apple-signed version of your app as an intruder and won’t allow it to launch: Its code signature does not match the one expected by your app’s existing container.
If you try to run the Apple-signed version of your app, you get a crash report containing a statement similar to this:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL) The solution is to adjust the access control list (ACL) on your app’s container to recognize the Apple-signed version of your app. Specifically, you add the designated code requirement of the Apple-signed version of your app to the app container’s ACL.
Also, its the same problem with you. Here.
0 comments:
Post a Comment