Running xcodebuild from a forked terminal

Question

I\'m trying to setup an automated build server for an iPhone application. I\'d like to be able to have nightly adhoc beta builds so that testers can follow the development.<

Answer 1

Could you use security list-keychains -s ${HOME}/Library/Keychains/login.keychain inside the build process to explicitly add your login keychain to the search list? It seems like from the forked Terminal, the build process doesn't see your user keychain. That could make sense if the keychain search list is based on your current security session - a forked terminal session would leave the login session just as if you ssh over the loopback connection.

Answer 2

I am using Atlassian Bamboo 2.7 and OS X 10.7.3 Lion and I've tried every approach found in the thread but I was still getting the "user interaction not allowed" error.

The problem was that, in a remote terminal session (as "superuser" such as in the case of Bamboo or another automated build system), the keychain that needs to be unlocked containing the signing certificates are different from what you would normal see (such as was shown by Yann in here) when you are not superuser.

What ultimately worked for me was to do the following:

1. log in as System Administrator as described here
2. create the signing-only keychain (e.g., ios.keychain)
3. add the signing certificates to it (along with the WWDRCA certificate)

Verify it by going su and running security list-keychains on the terminal. You should see the ios.keychain among the list. (sudo security list-keychains won't show the same thing):

sh-3.2# security list-keychains
"/private/var/root/Library/Keychains/login.keychain"
"/Library/Keychains/ios.keychain"
"/Library/Keychains/System.keychain"

I've found that you still have to add ios.keychain to your search scope before doing the unlock-keychain command. In your build script, have the following lines run:

KEYCHAIN=/Library/Keychains/ios.keychain
# the -s option adds $KEYCHAIN to the search scope, while the -d option adds $KEYCHAIN to the system domain; both are needed
security -v list-keychains -d system -s $KEYCHAIN 
security -v unlock-keychain -p bambooiphone $KEYCHAIN

Answer 3

If you're executing xcodebuild as root (which you are when you sudo), you need to log in as root and put your signing certificates in root's keychain. Then unlock the keychain with security as above.

Answer 4

Ok, the problem was two things for me, 1st was unlocking the keychain;

security unlock-keychain login.keychain

Second was (empty) passphrase,

security import blahblahbackup.p12 -k login.keychain -T /usr/bin/codesign -P ""

UPDATE: A had a little problem later, when the script is triggered from a web script or sth. like that. It just sees /Library/Keychains/System.chain. So i found a dirty workaround (which may lead to security issues but ok for me);

• setup pubkey ssh login (from user that wants to call build script, to actual user which has certificates and will run xcodebuild) in my case, it's same user. Apache is working as someuser and everything for build is setup on someuser.

• and my php script (for triggering build) was calling ~/build-script. I've changed that like this:

  ssh someuser@localhost ~/build-script

so it works in a real tty, and all keychain is accessible, everything works fine.

Answer 5

If you're running security list-keychains and seeing your custom keychain appear SOMEWHERE in the list but it still doesn't work, it could be that you're running into the issue I had whereby the keychains are checked in order from the search list, and since I wasn't unlocking login.keychain in my SSH session, it would fail there rather than move to the next keychain in the list, which was the custom one I wanted to unlock.

Setting the search list to a custom keychain which you unlock with security unlock-keychain works. Using this method from Yann's answer will also remove your login.keychain from the search list.

To preserve login.keychain:

security list-keychains -s ~/Library/Keychains/custom.keychain ~/Library/Keychains/login.keychain

This way, when using the GUI session at the machine you will still have access to login.keychain items, but code signing will check the custom keychain first, which succeeds if you've unlocked it.

Answer 6

I did:

• delete login.keychain from list

• create own keychain in $HOME/Library/Keychains/

• add it to keychain list (I did not specify any specific domain)

• set it as default

• call security unlock-keychain on it

• add global signing certificate (WWDRCA) to it

• import private key and both Development and Distribution certificates to it

If there's login.keychain, I still get "User interaction not allowed" error. Thus deleting login.keychain using security delete-keychain finally helped!