Starting with macOS Sierra, I can't import a codesign-identity into a keychain with /usr/bin/security any more without usr/bin/codesign UI-prompting for access when using this identity. This breaks the packaging scripts of build server. There seems to be no workaround. This affects custom created keychains, but also the login.keychain.
Steps to Reproduce: Execute the following commands in Terminal (requires a signing identity to be available to import):
security create-keychain -p test buildagent.keychain
security unlock-keychain -p test buildagent.keychain
security list-keychains -d user -s buildagent.keychain
security default-keychain -s buildagent.keychain
security import identity.p12 -k buildagent.keychain -P password -T /usr/bin/codesign
codesign -vfs '$IDENTITY' '${PRODUCT}' --keychain 'buildagent.keychain'
Result: macOS shows a UI-prompt asking for permission to access the previously imported private key.
I have tried many workarounds, but nothing seems to work:
- Using the new .keychain-db extension when specifying the keychain-name
- Using the login.keychain instead of the custom one
- Importing the p12 with -A ('Allow any application to access the imported key')
- Importing the Cert und Key separately (being extracted from the p12 before with openssl pkcs12)
Importing the identity definitely works, I can see the cert and key when displaying the contents of the keychain in the Keychain Access application. The access control setting for the private key is also correctly configured (with the desired codesign exception rule).
How can I avoid the UI prompt from Sierra?
The command you need to use is as follows:
security set-key-partition-list -S apple-tool:,apple: -s -k keychainPass keychainName
Please have in mind that this command line tool works like the list-keychains's way of modification. If you execute set-key-partition-list with a single value it will overwrite all partitionIDs in the certificates. It won't validate the values passed.
What this command does is that it sets the PartitionIDs (items after -S separated by comma) for keys that can sign (-s) for a specific keychain.
The actual partitionID that allows the codesigning is apple:.
I am not aware what apple-tool: is doing as it is not documented, but it was there after importing the key with security import so I'm keeping it in order to avoid breaking people who copy-paste the command.
This change was introduced with Mac OS Sierra and is not documented (or at least I could not find documentation). As of Oct 16 the man page for security still doesn't list this command.
For more information you can refer to this bug report - http://www.openradar.me/28524119
For those who are having this issue with Travis or other CI, you have to add codesign in the application id list.
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k keychainPass keychainName
P.S:
I'm using keychainName.keychain (adding .keychain)
The command from this answer only unlocked the keychain for me, but I still had the UI-prompt asking whether the current application could use the key.
I prevented the prompt like this:
Go to the keychain in Keychain Access, double click on all the keys there, and in the tab Access Control, check 'Allow all applications to access this item'.
I was able to upload the new keychain file then to my Jenkins build server, where it is unlocked by the Keychains and Provisioning Profiles Plugin. The build now succeeds signing.
For some reason the security set-key-partition-list did not work for me.
I solved it by using the -A option when importing the certificate in the keychain:
security import ${P12_FILE} -k ${KEYCHAIN_PATH} -P ${P12_PASSWORD} -A
There is no need to use the security set-key-partition-list afterwards.
This option allows any application to access the imported key without warning. Hence, it prevents the prompt from showing up. Note that it is insecure as the key is not protected but depending on your build context it might help.
On top of that the keychain must be added to the search list:
security list-keychains -s ${KEYCHAIN_PATH}
Then the keychain should be unlocked. Otherwise a prompt asking for the keychain password will be displayed:
security unlock-keychain -p ${KEYCHAIN_PASSWORD} ${KEYCHAIN_PATH}
Eventually the auto-lock timeout should be disabled. This is in case the build is quite long and the keychain re-locks itself:
security set-keychain-settings ${KEYCHAIN_PATH}
After trying many different solutions, what worked for me was simply changing the password of my keychain.
- Finder > Go > Utilities
- Open the Keychain Access utility.
- Not sure if I needed to do this step: In the left sidebar of the Keychain Access utility, click on My Certificates. Look at the Keychain column to confirm which Keychain your apple developer certificate is in. In my case it was in the "login" keychain.
- Change the password for the keychain from the previous step. You might want to trying locking it then unlocking it, if it's locked. You change the password by clicking on the relevant keychain ("login", in my case) and then selecting "Change Password..." from the Edit menu of the Keychain Access utility.
- The next time I ran the archive step in Xcode (in the Product menu) I was eventually prompted for a keychain password and I entered the password for my "login" keychain. Then it worked. When it finished I saw an Archives screen with my app listed in it.
Also if your app was build more than 5 minutes - you can run out of custom keychain lock timer and receive -1=ffffffff error. So disable keychain lock as tmp solution.
来源：https://stackoverflow.com/questions/39868578/security-codesign-in-sierra-keychain-ignores-access-control-settings-and-ui-p