공동 디자인을 사용하여 OSX 앱에 서명하려고하는“사용자 상호 작용이 허용되지 않습니다”
자동화 된 빌드는 Jenkins에서 실행됩니다. 빌드 자체는 슬레이브에서 실행되며 슬레이브는 SSH를 통해 실행됩니다.
오류가 발생합니다.
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.
나는 지금까지 다른 게시물에서 본 모든 제안을 시도했습니다.
- 서명하기 직전에 보안 잠금 해제 키 체인을 사용하여 키 체인의 잠금을 해제합니다.
- 서명 키를 자체 키 체인으로 이동
- 서명 키를 로그인 키 체인으로 이동
- 서명 키를 시스템 키 체인으로 이동
- 키가 포함 된 키 체인으로 만 목록 키 체인을 수동으로 설정
모든 경우에 동일한 오류가 발생합니다.
문제를 진단하기 위해 로컬 터미널에서 "security unlock-keychain"명령을 실행하려고 시도했지만 실제로 키 체인을 잠금 해제하지 않는 것으로 나타났습니다. 키 체인 액세스를 보면 잠금 기호가 여전히 있습니다. 이것은 명령 줄에 암호를 전달하거나 암호를 묻는 메시지를 표시하는지 여부입니다. GUI를 사용하여 동일한 키 체인을 잠금 해제하면 암호를 묻는 메시지가 표시되고 잠금이 해제됩니다. 내가 실행하는 경우 또한, 나는, "보안 잠금 - 키 체인" 할 즉시 명령을 실행 한 후 키 잠금을 참조하십시오. 이렇게하면 잠금 해제 키 체인이 실제로 작동하지 않는다고 생각합니다. 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 에서 제안을 시도하기 전까지는 아무것도 도움이되지 않았습니다 . 감사합니다 ashish agrawal!
GUI를 통해 빌드 사용자에 로그인하고 키 체인 액세스를여십시오. 서명 개인 키를 선택하고 마우스 오른쪽 단추를 클릭 한 후 정보 입수를 선택하고 액세스 제어 탭으로 변경 한 후 "모든 응용 프로그램이이 항목에 액세스하도록 허용"을 선택하십시오.
글쎄, 나는 오늘 내 자신의 질문에 대답 할 것 같아요. 왜냐하면 2 일 반 이상 찌른 후에 시도한 것 중 하나가 효과가 있었던 것 같습니다. 나는 지금 그것에서 뒤로 물러서 고 그것이 계속 작동하기를 희망합니다.
본질적으로 -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
수율하지 않는 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}"
This is redundant if you created the Keychain above, but if the Keychain already existed it is necessary.
Remove the defaults from the Keychain
security set-keychain-settings "${TESTING_KEYCHAIN}"
By not specifying any arguments this will set the auto-lock timeout to unlimited and remove auto-lock on sleep.
Import your signing certs from a .p12
security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign
Import the certs and gives codesign
access through the -T
option.
Set the ACL on the keychain
security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"
This is a requirement that many people miss. You can see what macOS does by using dump-keychain. Which in the case of codesigning requires apple:
and apple-tool:
. -s
refers to signing certificates.
Gitlab-Runner, Jenkins and the like
One very important thing for any CI-type runner or build system is to make sure the process is started from launchd
correctly. Make sure your plist contains <SessionCreate> </true>
.
Not correctly matching the the owner of the keychain with the build process and making sure a security session is created will result is all sorts of headaches. Diagnostically speaking you can introduce list-keychains
and see if the output matches your expectations.
This is from the launchd.plist
man-page:
SessionCreate <boolean>
This key specifies that the job should be spawned into a new security audit session rather than the default session for the context is belongs to. See auditon(2) for details.
UserName <string>
This optional key specifies the user to run the job as. This key is only applicable for services that are loaded into the privileged system domain.
GroupName <string>
This optional key specifies the group to run the job as. This key is only applicable for services that are loaded into the privileged system domain. If UserName is set and GroupName is not, then the group will be set to the primary group of the user.
Finally codesign
You can lookup the signing certificates hash using find-identity
security find-identity -p codesigning -v
Codesign a framework, dylib, etc.
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"
Codesign the app bundle
/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"
Final notes - if you look at how Xcode does it they set CODESIGN_ALLOCATE
to use the one contained in Xcode, not in /usr/bin
.
export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"
The search path is set to ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}
, where PLATFORM path is the /usr/bin directory for the given target SDK and TOOLCHAIN_PATH is the /usr/bin for the Xcode host tools.
So this is the command that works. -A
is to prevent Mac from asking password. Importing to system.keychain doesn't require an GUI.
sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A
My keychain was locked. It resisted my advances to change that fact...
Keychain Access
-> Keychain First Aid
-> Repair
, et voilá!
Unlocking the keychain is not enough. You also have to set the private key access to "Allow all apps to access this item". And to do that from command line requires reimporting the key. So to take things at a time:
Unlock the login keychain if it is locked. It shouldn't be locked though, but anyway here's how you do that:
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"
If for some reason your build machine has the login keychain locked, and you don't want to expose that password in a script, then you should use a different keychain. You can create one on the spot and use that in the previous and the following command. To create one on the spot:
security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain
Then import your certificates and associated private keys into the login keychain using the -A parameter. Note that you don't need to sudo for all this...
security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A
The -A parameter is what will make your private key to be set to "Allow all apps to access this item"
So using all these you should be able to make a script that installs the required certificate to build a release ipa and sign it without prompt. You can store the .p12 file in your repo, so any machine can build your ipa without requiring manual setup.
Import your keys to System keychain. You can use this command:
sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign
So I tried every answer here and something wasn't quite adding up. Finally I figured out when I rebooted my CI service, it was running under a different user than I had expected. Changing to the user that actually had access to the key in their login chain fixed everything. This may not be a common problem, but wanted to document my specific reason for this error, in case it happens to others.
For me nothing worked seems have to reinstall Xcode all over again. Jenkins keeps giving the same error. You would save lot of time if you just move Xcode installation to Trash and reinstall. Ensure you run the codesign command from command line atleast once.
Even after if you get the same error try setting 'Unlock Keychain?' property within Jenkins and give path to your login.keychain under /Users/${USER}/Library/Keychains/login.keychain
I hope god be with you after that.
In my case, this was caused by a keychain being created with a default timeout of 300s and a long xcode compile lasting more than 300s. The workaround, for me, was to invoke:
security set-keychain-settings -t <longer timeout in seconds> <keychain>
immediately after creating the temporary keychain.
I ran through all these suggestions and was still having problems using fastlane's gym
in a Jenkins job. I had the certificate installed and keychain unlocked, and was able to codesign on the slave when I manually ran the codesign command on the command line.
As a workaround, if Jenkins connects to the slave using JNLP instead of SSH, you'll be able to codesign.
For me it happens when there is a second keychain added manually and it's locked. For some reason codesign
tries to access the locked keychain and fails even though the certificates are in the login keychain (and is unlocked). Unlocking the second one solves the problem. Just doesn't make sense to me.
Apart from unlocking keychain (as mentioned in another answers), you need to allow access from all applications to Xcode authentication token in keychain:
- Select "login" keychain
- Select "All Items" category
- Search for "xcode" keyword
- Select "Allow all applications to access this item" for all Xcode tokens
- Don't forget to add unlock keychain step (from previous answers)
위의 여러 가지 해결책을 시도한 후. 내가 가진 한 가지 요소는 ION Console을 사용하여 빌드를 시작한다는 것입니다. 터미널 앱에서 빌드하는 것으로 다시 전환했을 때 모든 것이 잘 작동했습니다.
'IT story' 카테고리의 다른 글
WSDL, SOAP 및 REST 란 무엇입니까? (0) | 2020.06.22 |
---|---|
.csproj 파일을 편집하는 방법 (0) | 2020.06.22 |
유형을 삭제하지 않고 색인 / 유형에서 모든 문서 삭제 (0) | 2020.06.22 |
'int'와 'int'사이에 암시 적 변환이 없으므로 조건식의 유형을 확인할 수 없습니다. (0) | 2020.06.22 |
사용자 정의 리터럴은 C ++에 어떤 새로운 기능을 추가합니까? (0) | 2020.06.22 |