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

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!

Answer 2

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

Answer 3

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

Answer 4

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

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.

Answer 6

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?