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?
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.
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:
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:
Then the keychain should be unlocked. Otherwise a prompt asking for the keychain password will be displayed:
Eventually the auto-lock timeout should be disabled. This is in case the build is quite long and the keychain re-locks itself:
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 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 withsecurity 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
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.
After trying many different solutions, what worked for me was simply changing the password of my keychain.