我们的自动化版本正在Jenkins上运行。构建本身在从属服务器上运行，并且从属服务器通过SSH执行。

我收到一个错误：

00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.

我已经尝试了到目前为止在其他帖子中看到的所有建议：

• 签名前立即使用安全性解锁钥匙串以解锁钥匙串。
• 将签名密钥移到其自己的钥匙串中。
• 将签名密钥移到登录密钥链中。
• 将签名密钥移到系统密钥链中。
• 手动将列表钥匙串设置为仅包含钥匙的钥匙串。

在所有情况下，我都会遇到相同的错误。

为了诊断问题，我尝试在本地终端上运行“ security unlock-keychain”命令，发现它实际上并没有解锁钥匙链-如果我在“钥匙串访问”中查看，则锁符号仍然存在。无论是在命令行上通过密码还是让其提示输入密码，都是这种情况。使用GUI解锁相同的钥匙串会提示我输入密码，然后将其解锁。另外，如果我运行“ security lock-keychain”，则在运行命令后我会立即看到密钥锁。这使我认为解锁钥匙串实际上不起作用。我在Lion（我们用于构建奴隶）和Mavericks（我正在开发）上遇到相同的行为。

接下来，我尝试将-v添加到所有安全命令中：

list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
        "/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.

由此看来，列表钥匙串是行不通的。也许都不行。：/

这里也有类似的问题。解决方案很有趣-在launchctl中将“ SessionCreate”设置为true。但是我不是在主服务器上构建的-我的构建过程是从从属构建计算机上的SSH开始的。在运行“ SessionCreate”时，也许有一种命令行方式可以执行launchctl在做什么？

我也一直在战斗。在我尝试通过http://devnet.jetbrains.com/thread/311971提出建议之前，没有任何帮助。谢谢ashash的农作！

通过GUI登录您的构建用户，然后打开“钥匙串访问”。选择您的签名私钥，右键单击，选择“获取信息”，更改为“访问控制”选项卡，然后选择“允许所有应用程序访问此项目”。

好吧，我想我今天可以回答我自己的问题，因为在经过两天半的时间刺伤之后，我尝试过的其中一项工作似乎奏效了。我现在要退出它，希望它能继续工作。

从本质上讲，它似乎归结为-d system无法实际工作。因此，应该对此处周围其他问题的很多答案进行更新以反映这一点。

security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
         --resource-rules src/AppResourceRules.plist --timestamp --verbose \
         "$APP"

没有其他答案对我有用。

最终救了我的是这篇文章

总结起来，这可能是由于默认超时5分钟引起的，该超时在长时间构建后会触发此错误。

修理：

security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain

尝试调用security unlock-keychain和codesign作为单行命令。这对我有帮助。就像是：

security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>

使用安全性为/ usr / bin / codesign创建钥匙串

导入证书并以编程方式使其与Codesign结合使用，无需使用登录或系统钥匙串，也无需向CodeSign的某些上帝祈祷。您只需要设置正确的权限即可。我建议创建一个专门用于代码签名的新钥匙串。

这些天来codesign不产生errSecInternalComponent您需要正确的分区列表（ACL）。我将逐步执行以下步骤：

创建钥匙串

security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

此时，钥匙串已解锁，但不会出现在 Keychain Access。

将新的钥匙串添加到搜索列表

security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[@]}"

将新的钥匙串添加到列表中。如果您不首先从中获取原始列表，则list-keychains不再需要login.keychain在搜索列表中。

解锁钥匙扣

security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

如果您在上面创建了钥匙串，那么这是多余的，但是如果钥匙串已经存在，则有必要。

从钥匙串中删除默认设置

security set-keychain-settings "${TESTING_KEYCHAIN}"

通过不指定任何参数，这会将自动锁定超时设置为无限制，并删除睡眠时的自动锁定。

从.p12导入您的签名证书

security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign

导入证书，并codesign通过-T选项。

在钥匙串上设置ACL

security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

这是许多人错过的要求。您可以使用dump-keychain查看macOS的功能。如果是代码签名，则需要apple:和apple-tool:。-s指签署证书。

Gitlab-Runner，Jenkins等

对于任何CI型运行器或构建系统来说，一件非常重要的事情是确保launchd正确启动该过程。确保您的plist包含<SessionCreate> </true>。

如果不正确地将钥匙串的所有者与构建过程进行匹配，并确保创建了安全会话，则会令人头疼。从诊断角度来说，您可以介绍list-keychains并查看输出是否符合您的期望。

这是从launchd.plist手册页：

SessionCreate <boolean>

此项指定应将作业派生到新的安全审核会话中，而不是上下文所属的默认会话。有关详细信息，请参见auditon（2）。

UserName <string>

此可选键指定用户以其身份运行作业。该密钥仅适用于已加载到特权系统域中的服务。

GroupName <string>

此可选键指定用于运行作业的组。该密钥仅适用于已加载到特权系统域中的服务。如果设置了UserName而没有设置GroupName，则该组将被设置为用户的主要组。

最终代号

您可以使用以下方法查找签名证书哈希 find-identity

security find-identity -p codesigning -v

共同设计框架，dylib等。

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"

共同设计应用程序捆绑包

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"

最后说明-如果您查看Xcode的工作方式，则将其设置CODESIGN_ALLOCATE为使用Xcode而不是Xcode中包含的代码/usr/bin。

export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"

搜索路径设置为${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}，其中PLATFORM路径是给定目标SDK的/ usr / bin目录，TOOLCHAIN_PATH是Xcode宿主工具的/ usr / bin。

将您的钥匙放在系统钥匙串中

所以这是有效的命令。-A是为了防止Mac询问密码。导入到system.keychain不需要GUI。

sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A

我的钥匙串已锁定。它拒绝了我改变这一事实的进展。

Keychain Access- > Keychain First Aid- > Repair，等瞧！

解锁钥匙串还不够。您还必须将私钥访问权限设置为“允许所有应用程序访问此项目”。要从命令行执行此操作，需要重新导入密钥。因此，一次取东西：

解锁登录钥匙串（如果已锁定）。它不应该被锁定，但是无论如何这是您的操作方式：

security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"

如果由于某种原因，您的构建计算机已锁定了登录钥匙串，并且您不想在脚本中公开该密码，则应使用其他钥匙串。您可以在现场创建一个，然后在上一个和下一个命令中使用它。当场创建一个：

security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain

然后，使用-A参数将证书和关联的私钥导入登录密钥链。请注意，您无需为所有这一切而须藤...

security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A

-A参数将使您的私钥设置为“允许所有应用访问此项目”

因此，使用所有这些内容，您应该能够制作一个脚本，该脚本安装所需的证书以构建发行版ipa并在没有提示的情况下对其进行签名。您可以将.p12文件存储在存储库中，因此任何计算机都可以构建ipa，而无需手动设置。

除了解锁钥匙串（如另一个答案中所述）之外，您还需要允许所有应用程序访问钥匙串中的Xcode身份验证令牌：

• 选择“登录”钥匙串
• 选择“所有项目”类别
• 搜索“ xcode”关键字
• 为所有Xcode令牌选择“允许所有应用程序访问此项目”
• 不要忘记添加解锁钥匙串步骤（来自先前的答案）

将密钥导入系统钥匙串。您可以使用以下命令：

sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign

因此，我在这里尝试了所有答案，但并没有完全解决。最终，我发现重新启动CI服务时，该服务在与预期不同的用户下运行。更改为实际有权访问其登录链中密钥的用户可以解决所有问题。这可能不是一个普遍的问题，但是希望记录下我对此错误的具体原因，以防其他情况发生。

对我而言，似乎没有任何效果，必须重新安装Xcode。詹金斯（Jenkins）不断犯同样的错误。如果仅将Xcode安装移至Trash并重新安装，则可以节省大量时间。确保至少从命令行运行一次codesign命令。

即使遇到相同的错误，也请尝试设置“解锁钥匙串？”。属性在Jenkins中，并在/Users/${USER}/Library/Keychains/login.keychain下提供您的login.keychain的路径

我希望那之后上帝与你同在。

在我的情况下，这是由于创建的钥匙串的默认超时为300s，并且长时间的xcode编译持续了300s以上所致。对我来说，解决方法是调用：

security set-keychain-settings -t <longer timeout in seconds> <keychain>

创建临时钥匙串后立即。

我经历了所有这些建议，但在使用fastlane的过程中仍然遇到问题 gym在詹金斯（Jenkins）的工作中。我安装了证书并且已解锁钥匙串，并且当我在命令行上手动运行codesign命令时，能够在从属服务器上进行代码签名。

解决方法是，如果Jenkins使用JNLP（而不是SSH）连接到从站，则可以进行代码签名。

对我来说，它发生在手动添加第二个钥匙串并将其锁定时。由于某些原因codesign，即使证书在登录钥匙串中（并且已解锁），也会尝试访问锁定的钥匙串并失败。解锁第二个解决了这个问题。只是对我没有意义。

在尝试了以上几种解决方案之后。我意识到我拥有的一个因素是，我正在使用ION Console开始构建。当我切换回使用终端机应用程序进行构建时，一切正常。