“不允许用户交互”尝试使用codesign为OSX应用程序签名
我们的自动化构建在Jenkins上运行。构建本身在从服务器上运行，从服务器通过SSH执行。
我得到一个错误：
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.到目前为止，我已经在这里的其他帖子中尝试了所有我看到的建议：
使用安全解锁列表- keychain在签名前立即解锁keychain.
- Moving将签名密钥移出到自己的keychain.
- Moving中将签名密钥移入登录keychain.
- Moving将签名密钥移入系统keychain.
- Manually设置列表-
- 仅将包含密钥的密钥链。
在所有情况下，我都会得到相同的错误。
为了诊断这个问题，我尝试在我的本地终端上运行"security unlock- keychain“命令，发现它实际上并没有解锁密钥链-如果我查看密钥链访问，锁符号仍然在那里。无论我是在命令行上传递密码，还是让它提示我输入密码，都会出现这种情况。使用GUI解锁相同的钥匙链将提示我输入密码，然后解锁。此外，如果我运行"security lock-keychain"，我确实在运行命令后立即看到了密钥锁。这让我认为unlock-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.从这一点上看，列表密钥链似乎是不起作用的。也许两个都不管用。:/
有一个similar question here。解决方案很有趣--在启动set中将"SessionCreate“设置为true。但是我不是在主机器上构建--我的构建过程是从从属构建机器上的SSH开始的。也许有一种命令行方法可以在运行"SessionCreate“时执行启动way正在做的事情？
回答 17
Stack Overflow用户
发布于 2013-11-26 11:45:50
好吧，我想我今天可以回答我自己的问题了，因为在两天半的时间里，我尝试过的一件事似乎起作用了。我现在要放弃它，希望它能继续工作。
从本质上讲，它看起来像是因为-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"Stack Overflow用户
发布于 2014-03-25 22:41:02
我也一直在与此作斗争。在我在http://devnet.jetbrains.com/thread/311971上尝试这个建议之前，什么都没有用。感谢ashish agrawal！
通过GUI登录您的构建用户，并打开Keychain访问。选择您的签名私钥，右键单击，选择Get Info，更改到Access Control选项卡，然后选择"Allow all application to access this item“。
Stack Overflow用户
发布于 2018-08-31 20:56:17
使用安全性为/usr/bin/codesign创建钥匙链
导入证书并让它以编程方式与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[@]}"将新的Keychain添加到列表中。如果你不先从list-keychains中获取原始列表，你的搜索列表中就不再有login.keychain了。
解锁钥匙链
security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"如果您创建了上面的Keychain，这是多余的，但如果Keychain已经存在，则它是必要的。
删除Keychain中的默认值
security set-keychain-settings "${TESTING_KEYCHAIN}"通过不指定任何参数，这会将自动锁定超时设置为无限制，并删除睡眠时的自动锁定。
从.p12导入签名证书
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign导入证书并通过-T选项授予codesign访问权限。
在密钥链上设置ACL
security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"这是许多人忽略的要求。您可以使用dump-keychain查看macOS的功能。这在协同设计的情况下需要apple:和apple-tool:。-s指的是签名证书。
我的签名证书呢？
确保您可以找到您的证书总是一个好主意
security find-identity -p codesigning -v /path/to/keychainGitlab-Runner、Jenkins等
对于任何CI类型的runner或构建系统来说，一件非常重要的事情是确保进程从launchd正确启动。确保您的plist包含<SessionCreate> </true>。
没有正确匹配密钥链的所有者和构建过程，并确保创建了安全会话，这将导致各种令人头疼的问题。从诊断的角度讲，您可以引入list-keychains并查看输出是否符合您的预期。
这来自launchd.plist手册页：
SessionCreate <boolean>
此键指定作业应派生到新的安全审核会话中，而不是上下文所属的默认会话中。详细信息请参见auditon(2)。
UserName <string>
此可选键指定运行作业的用户身份。此密钥仅适用于加载到特权系统域中的服务。
GroupName <string>
此可选键指定要以其身份运行作业的组。此密钥仅适用于加载到特权系统域中的服务。如果设置了UserName，但未设置GroupName，则组将被设置为用户的主要组。
示例/Library/LaunchDaemons/com.company.gitlab-runner.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>com.company.gitlab-runner</string>
<key>SessionCreate</key><true/>
<key>KeepAlive</key><true/>
<key>Disabled</key><false/>
<key>UserName</key>
<string>bob</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/opt/gitlab-runner/bin/gitlab-runner</string>
<string>run</string>
<string>--working-directory</string>
<string>/Users/bob/gitlab-runner</string>
<string>--config</string>
<string>/Users/bob/gitlab-runner/config.toml</string>
<string>--service</string>
<string>gitlab-runner</string>
<string>--syslog</string>
</array>
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
</dict>
</dict>
</plist>注册runner
gitlab-runner register \
--non-interactive \
--tls-ca-file "{{ gitlab_runner_dir }}/certs/git.company.com.crt" \
--config "{{ gitlab_runner_dir }}/config.toml" \
--builds-dir "{{ gitlab_runner_dir }}/builds" \
--url "{{ gitlab_ci }}" \
--registration-token "{{ gitlab_token }}" \
--name "{{ computername }}" \
--tag-list "{{ gitlab_runner_tags }}" \
--output-limit 16384 \
--executor shell \
--shell bash最后是联合设计
您可以使用find-identity查找签名证书散列
security find-identity -p codesigning -v在对Xcode进行签名之前，将环境变量CODESIGN_ALLOCATE设置为使用Xcode附带的codesign_allocate，而不是在/usr/bin中。
export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"共同设计框架、dylib等。
如果您正在手动进行协同设计，请从frameworks和dylibs开始，在它们都签名之后，再对.app签名。或者换句话说--你自下而上的共同设计。
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"共同设计应用程序包
在对所有其他可签名项进行签名后，对.app本身进行签名。从理论上讲，你可以用--deep一次性完成这一切，然而，你仍然需要确保你的应用程序有权限和可能的其他标志。
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"传递给所有项目的标志：
--timestamp=none禁用时间戳
应用程序签名步骤的其他标志：
--entitlements /path/to/entitlements.xcent新entitlements--preserve-metadata=entitlements保持当前entitlements
https://stackoverflow.com/questions/20205162
复制相似问题