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.

I've setted up xcode successfully xcode to perform adhoc builds and I can also launch the build from the command line:

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

The problem I'm having is that the following line doesn't work from a forked terminal (using nohup or screen) and failed with the following

CodeSign error: Code Signing Identity 'iPhone Distribution: XXXXX' does not match any code-signing certificate in your keychain. Once added to the keychain, touch a file or clean the project to continue.

I've checked my environment variables in my shell and in nohup or screen and didn't found a clue. I guess my problem is that the forked terminal can't access to the keychain but I have no clue on how to allow it.

Thanks for your help

Sidoon

Can you paste in the command you are using to launch terminal? – Dietsche

The first terminal is launched opening Terminal.app The second with screen – Sidoon

Could the problem be solved with sudo? – Hemitrope

I've just tried running the command with various sudo combination always with the same CodeSign error – Sidoon

This issue can still crop up regardless of unlocking the login keychain. The only thing that works for me is to use the Keychain Access app and copy the distribution/adhoc certificates+keys into the System keychain. – Flyboat

Answer 1

I had te error User interaction is not allowed and solved it by unlocking the keychain first

security unlock-keychain /Users/yannooo/Library/Keychains/login.keychain

I've also tried to put my certs in the System's keychain and it was working. My final solution was to put all my iPhone related certs in a dedicated keychain named iPhone.keychain using the Keychain Access application

security list-keychains -s /Users/yannooo/Library/Keychains/iPhone.keychain 
security unlock-keychain -p keychainpassword /Users/yannooo/Library/Keychains/iPhone.keychain 

Sidoon

You might want to copy these comments into your original question, rather than having them as "answers" – Alaric

This is what I intended to do, but it was too long to fit in a comment. And AFAIK comments can't be formatted. – Sidoon

This solve my problem of "User interaction is not allowed". Nice trick. – Hiphuggers

In case it's of interest to anyone: none of the above worked for me, initially, because I was in my home directory and referring to the keychain relative to the current path. (Library/Keychains/login.keychain instead of /Users/platypus/Library/Keychains/login.keychain.) When I switched to using fully qualified paths, it was fine. – Grossman

It worked for me too, but I had to set the iPhone keychain as default since xcodebuild only seems to use the default one. Might help for somebody. – Duress

None of the above worked for me either, until I manually copied the certificates from the Login keychain to the System keychain. It also removes the need to use security to unlock the keychain in code – Flyboat

None of the instructions was of any help until I put all my certificates (yes, ALL: development certs, the WWDCRA, code signing etc.) into a newly created keychain file and unlocking it. Most instructions on the Internet focus on the "building", which is the easier part. This, unlocking the security access took the life out of me. But finally, latest Xcode (4.3.2) and iOS5 - people, DO IT IN YOUR OWN KEYCHAIN, not login or System! – Tibia

Solved my problem running ant and building a enterprise release via ssh. Thanks! – Nollie

Please note there is one other component to this. Access Control Lists. See my answer below. – Trenna

Answer 2

There are two (possibly three!) components to this. One is the keychain must be unlocked. Second, there is an access control list inside the keychain that tells which permissions are given to applications in the unlocked state. So even if you have the keychain successfully unlocked, if the ability to access the private key and sign with it isn't given to /usr/bin/codesign then you will still get this message. Finally, if you are on Mac OS Sierra, the default partition ID assigned to keys is incorrect in order to be compatible with the codesign binary.

The solution is as follows:

1) If you have access to the Keychain Access GUI, then you can manually grant every program or /usr/bin/codesign access by right clicking on your private key, selecting the "Access Control" tab and then selecting the "Allow all applications to access this item" radio or the list of "Always allow access by these applications" list.

2) If you are encountering this error, chances are you are trying to run codesign for a non-login user. In this case, you clearly don't have access to the "Keychain Access" GUI. For these cases, you verify the sign authorization missing for application <null>, which apparently means all applications, or specifically /usr/bin/codesign by using:

security dump-keychain -i login.keychain

However, you cannot add or modify access control attributes in interactive mode for some reason --only delete! You actually have to manually delete the key and re-add it to the keychain specifying the -T flag.

security import login.keychain -P "<password>" -T /usr/bin/codesign

Where -T specifies

-T  Specify an application which may access the imported key (multiple -T options are allowed)

3) If you are on Mac OS Sierra, modify the partition ID to include the apple partition. Presumably, this is the namespace assigned to codesign because it was distributed by Apple.

security set-key-partition-list -S apple-tool:,apple: -k "<password>" login.keychain

NOTE: The apple-tool partition is inserted by the security tool, so the command above preserves that partition. For more information on this aspect, see: http://www.openradar.me/28524119

Trenna

Thank you very much! This solved my problem. I added /usr/bin/codesign to my private key. – Nonstandard

Adding /usr/bin/codesign to the private key is the solution for our problems with codesigning. This should be the accepted answer. Thank you very much! – Jemmy

-T doesn't the same way anymore. You also have to set a partition list. https://mcmap.net/q/240013/-security-codesign-in-sierra-keychain-ignores-access-control-settings-and-ui-prompts-for-permission (Hi Mark!) – Mullens

Answer 3

Another solution :

• Open the Keychain Access
• Right click on the private key
• Select "Get Info"
• Select "Access Control" tab
• Click "Allow all applications to access this item"
• Click "Save Changes"
• Enter your password
• Enjoy

Thacher

This helped me as well for a new cert/key I was using in a TeamCity build. – Esmerolda

Answer 4

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.

Doctrinal

Not for me. If I login interactively to the build account, I can add keychains to my search list. If I am logged in as someone else, I can't. – Disuse

Answer 5

update for people running into similar issues with Jenkins:

If you set up your Mac to launch jenkins via LaunchDaemons, you need to make sure to add

<key>SessionCreate</key>
<true />

So the whole ci.plist would look like so:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>Jenkins</string>
 <key>UserName</key>
 <string>user</string>
 <key>GroupName</key>
 <string>staff</string>
 <key>ProgramArguments</key>
 <array>
 <string>/usr/bin/java</string>
 <string>-Xmx512m</string>
 <string>-jar</string>
 <string>/path/to/jenkins/jenkins.war</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>
 <key>EnvironmentVariables</key>
   <dict>
     <key>JENKINS_HOME</key>
     <string>/path/to/jenkins/home</string>
   </dict>
 <key>SessionCreate</key>
 <true />
</dict>
</plist>

I've been stuck wit the same issue as many people above have. Specifically I experienced the issue when running from a Jenkins shell script I got the same ** User interaction is not allowed ** error. When running from an ssh shell, my script worked fine.

The difference that most people have also seen is that if you run security list-keychain you'd get:

$ security list-keychain
  "/Library/Keychains/System.keychain"
  "/Library/Keychains/System.keychain"

But when running in the ssh shell, I'd get:

$ security list-keychain
    "/Users/<i>user_account_name</i>/Library/Keychains/login.keychain"
    "/Library/Keychains/System.keychain"

And most people will have all their keys/certs etc. in the user account keychain. Like some folks suggested it's easy to make a new key chain that is distinct from the user key chain, and reseve it for your XCode signing stuff. I ended up putting mine here: /Library/Keychains/sysiphone.keychain

I think the issue is that for my setup (and possibly for yours too), you're running in a different security preference domain (system vs. user). Finally -- here is how I got my sysiphone.keychain to show up:

$ sudo security list-keychains -d system -s "/Library/Keychains/sysiphone.keychain"
Password: *****
$ security list-keychains -d system
    "/Library/Keychains/sysiphone.keychain"

... and magically things started to build in Jenkins. Wow... that was about 4 hours down the drain for me. Sigh.

Jacques

This fixed my TeamCity builder problem. Thanks! – Semantic

"I ended up putting mine here: /Library/Keychains/sysiphone.keychain" Magically !! – Sitton

Answer 6

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.

Halifax

Answer 7

As another poster says,

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

But I think you only have access to the login.keychain when you are logged in, in the GUI context (I just tested on a system via SSH and screen, but which I also happen to be logged into via VNC).

It is apparently possible to use launchctl to select the GUI context and run the program, but I suspect that only works for the "logged in user" too.

If you try 'security show-keychain-info keychain-file' then you'll get the following error:

User interaction is not allowed

And that's a phrase to search with for some more info. The other solution is to put the certificate into your System keychain!

Entrance

Did you found solution "how to share" login or any keychain ? I mean use ssh or other ways (not GUI) to use Keychains. – Trickle

You will fix the 'user interaction is not allows' with the following command: security unlock-keychain -p "password" /Users/username/Library/Keychains/login.keychain-db – Devaney

Answer 8

I've looked at the security command an it appears that the keychains assigned to my terminal are not the same when forked. If I launched the security command in terminal I have:

$ security list-keychains
  "/Users/yannooo/Library/Keychains/login.keychain"
  "/Library/Keychains/System.keychain"

whereas when using screen I have the following output:

$ security list-keychains
    "/Library/Keychains/System.keychain"
    "/Library/Keychains/System.keychain"

Since my build certificates are stored in the login keychain, the code sign error I have looks normal.

Does anyone know how I could assign a keychain to a terminal? I've tried this without success

security login-keychain -s /Users/yannooo/Library/Keychains/login.keychain

Any ideas?

Sidoon

Using the Keychain Access app, manually copy the required certificates from the Login keychain to the System keychain. – Flyboat

brack, thank you! it works fine for me. But I'm afraid a bit about it - is it correct scheme ? thanks – Trickle

When you're seeing only two System.keychains, you're probably running the command as root, not your user. I ran into this exact problem when I accidentally ran the Bamboo Continuous Integration server as root instead of my user and tried to build and sign an app. – Theology

Answer 9

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

Ackerley

Answer 10

Unlocking the login keychain did not work for me. Creating a separate keychain using Keychain Access (called iOS) and then adding these commands to the build did work (when running Jenkins as my own user):

security -v list-keychains -d system -s ~/Library/Keychains/iOS.keychain; security -v unlock-keychain -p password ~/Library/Keychains/iOS.keychain;

This looks more promising, though: https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin#XcodePlugin-Userinteractionisnotallowed

Vanillic

Answer 11

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.

Lebar

Answer 12

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.

Leopard

Answer 13

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!

Lotetgaronne