xcode 从分叉终端运行 xcodebuild

Running xcodebuild from a forked terminal

提问by Yann Biancheri

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.

我正在尝试为 iPhone 应用程序设置自动构建服务器。我希望能够每晚进行临时测试版构建，以便测试人员可以跟踪开发。

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

我已经成功设置了 xcode xcode 来执行临时构建，我还可以从命令行启动构建：

xcodebuild -configuration AdHoc -sdk iphoneos2.2 clean build

xcodebuild -configuration AdHoc -sdk iphoneos2.2 干净构建

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

我遇到的问题是以下行在分叉终端（使用 nohup 或 screen）中不起作用，并且因以下原因而失败

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.

CodeSign 错误：代码签名标识“iPhone 分发：XXXXX”与您钥匙串中的任何代码签名证书都不匹配。添加到钥匙串后，触摸文件或清理项目以继续。

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.

我已经在我的 shell 和 nohup 或 screen 中检查了我的环境变量，但没有找到任何线索。我想我的问题是分叉终端无法访问钥匙串，但我不知道如何允许它。

Thanks for your help

谢谢你的帮助

回答by Yann Biancheri

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

我有 te 错误不允许用户交互并通过首先解锁钥匙串来解决它

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 Accessapplication

我还尝试将我的证书放在系统的钥匙串中并且它正在工作。我的最终解决方案是使用Keychain Access应用程序将所有与 iPhone 相关的证书放在名为 iPhone.keychain 的专用钥匙串中

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

回答by markshiz

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/codesignthen 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 codesignbinary.

这有两个（可能是三个！）组件。一是钥匙串必须解锁。其次，钥匙串内部有一个访问控制列表，它告诉处于解锁状态的应用程序被授予哪些权限。因此，即使您成功解锁了钥匙串，如果没有授予访问私钥并使用它签名的能力，/usr/bin/codesign那么您仍然会收到此消息。最后，如果您使用的是 Mac OS Sierra，分配给键的默认分区 ID 是不正确的，以便与codesign二进制文件兼容。

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.

1) 如果您有权访问钥匙串访问 GUI，那么您可以通过右键单击您的私钥，选择“访问控制”选项卡，然后选择“允许所有应用程序”来手动授予每个程序或 /usr/bin/codesign 访问权限访问此项”收音机或“始终允许这些应用程序访问”列表。

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

2) 如果您遇到此错误，很可能您正在尝试codesign为非登录用户运行。在这种情况下，您显然无权访问“钥匙串访问”GUI。对于这些情况，您验证signapplication 缺少的授权<null>，这显然意味着所有应用程序，或者特别是/usr/bin/codesign通过使用：

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 -Tflag.

但是，由于某些原因，您不能在交互模式下添加或修改访问控制属性——只能删除！您实际上必须手动删除密钥并将其重新添加到指定-T标志的钥匙串中。

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

Where -Tspecifies

哪里-T指定

-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 applepartition. Presumably, this is the namespace assigned to codesignbecause it was distributed by Apple.

3) 如果您使用的是 Mac OS Sierra，请修改分区 ID 以包含该apple分区。据推测，这是分配给的命名空间，codesign因为它是由 Apple 分发的。

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

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

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

注意：apple-tool分区是由security工具插入的，因此上面的命令会保留该分区。有关这方面的更多信息，请参见：http: //www.openradar.me/28524119

回答by Micha?l Witrant

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

• 打开钥匙串访问
• 右键单击私钥
• 选择“获取信息”
• 选择“访问控制”选项卡
• 点击“允许所有应用程序访问此项目”
• 点击“保存更改”
• 输入您的密码
• 享受

回答by Micha?l Witrant

Could you use security list-keychains -s ${HOME}/Library/Keychains/login.keychaininside 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 sshover the loopback connection.

您能否security list-keychains -s ${HOME}/Library/Keychains/login.keychain在构建过程中使用将您的登录钥匙串显式添加到搜索列表中？从分叉的终端看来，构建过程看不到您的用户钥匙串。如果钥匙串搜索列表基于您当前的安全会话，这可能是有意义的 - 分叉的终端会话将离开登录会话，就像您ssh通过环回连接一样。

回答by Bernt Habermeier

update for people running into similar issues with Jenkins:

对于遇到 Jenkins 类似问题的人的更新：

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

如果您将 Mac 设置为通过 LaunchDaemons 启动 jenkins，则需要确保添加

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

So the whole ci.plist would look like so:

所以整个 ci.plist 看起来像这样：

<?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.

我一直被困在与上面许多人相同的问题中。具体来说，我在从 Jenkins shell 脚本运行时遇到了这个问题，我得到了相同的 ** 不允许用户交互 ** 错误。从 ssh shell 运行时，我的脚本运行良好。

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

大多数人还看到的不同之处在于，如果您运行 security list-keychain，您将获得：

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

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

但是在 ssh shell 中运行时，我会得到：

$ 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

大多数人将在用户帐户钥匙串中拥有他们所有的密钥/证书等。就像有些人建议制作一个与用户钥匙链不同的新钥匙链很容易，并将其保留用于您的 XCode 签名内容。我最终把我的放在这里：/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:

我认为问题在于，对于我的设置（也可能是您的设置），您在不同的安全偏好域（系统与用户）中运行。最后——这是我如何让我的 sysiphone.keychain 出现：

$ 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.

......神奇的事情开始在詹金斯建立。哇......对我来说这大约是 4 个小时的流失。叹。

回答by Furkan Mustafa

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);

更新：后来遇到了一个小问题，当脚本是从网络脚本或某事触发时。像那样。它只看到/Library/Keychains/System.chain。所以我找到了一个肮脏的解决方法（这可能会导致安全问题，但对我来说没问题）；

• 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 someuserand 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

• 在我的情况下，设置 pubkey ssh 登录（从想要调用构建脚本的用户到拥有证书并将运行 xcodebuild 的实际用户），它是同一个用户。Apache 正在运行，someuser并且构建的所有内容都在someuser.

• 我的 php 脚本（用于触发构建）正在调用 ~/build-script。我已经改变了这样的：

  ssh someuser@localhost ~/build-script

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

所以它在真正的 tty 中工作，并且所有钥匙串都可以访问，一切正常。

回答by jrg

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).

但是我认为您只有在登录时才能在 GUI 上下文中访问 login.keychain（我刚刚通过 SSH 和屏幕在系统上进行了测试，但我也碰巧通过 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.

显然可以使用 launchctl 来选择 GUI 上下文并运行程序，但我怀疑它也只适用于“登录用户”。

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

如果您尝试“ security show-keychain-info keychain-file”，则会出现以下错误：

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!

这是一个用于搜索更多信息的短语。另一种解决方案是将证书放入您的系统钥匙串中！

回答by Yann Biancheri

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 screenI 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?

有任何想法吗？

回答by Aldrich Co

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.

我正在使用 Atlassian Bamboo 2.7 和 OS X 10.7.3 Lion，我已经尝试了线程中找到的所有方法，但仍然出现“不允许用户交互”错误。

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.

问题是，在远程终端会话中（作为“超级用户”，例如在 Bamboo 或其他自动构建系统的情况下），需要解锁的包含签名证书的钥匙串与您通常看到的不同（例如当您不是超级用户时，正如 Yann 在此处所示）。

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)

1. 按照此处所述以系统管理员身份登录
2. 创建仅签名钥匙串（例如，ios.keychain）
3. 向其中添加签名证书（以及 WWDRCA 证书）

Verify it by going suand running security list-keychainson the terminal. You should see the ios.keychain among the list. (sudo security list-keychainswon't show the same thing):

通过在终端上su运行并验证它security list-keychains。您应该在列表中看到 ios.keychain。（sudo security list-keychains不会显示相同的东西）：

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-keychaincommand. In your build script, have the following lines run:

我发现在执行unlock-keychain命令之前，您仍然需要将 ios.keychain 添加到您的搜索范围。在您的构建脚本中，运行以下几行：

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

回答by Kyle Robson

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):

解锁登录钥匙串对我不起作用。使用 Keychain Access（称为 iOS）创建一个单独的钥匙串，然后将这些命令添加到构建中确实有效（当以我自己的用户身份运行 Jenkins 时）：

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

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

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

不过，这看起来更有希望：https: //wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin#XcodePlugin-Userinteractionisnotallowed