Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching default keychain #350

Closed
jl-gogovapps opened this issue Mar 1, 2020 · 5 comments · Fixed by #847 or qatonda/runner#1
Closed

Switching default keychain #350

jl-gogovapps opened this issue Mar 1, 2020 · 5 comments · Fixed by #847 or qatonda/runner#1
Labels
bug Something isn't working question Further information is requested

Comments

@jl-gogovapps
Copy link

jl-gogovapps commented Mar 1, 2020

Describe the bug

Ultimately, I'm trying to use match/gym to build apps through a self-hosted runner.

I've tried many combinations of the following:

bundle exec fastlane run create_keychain
bundle exec fastlane run unlock_keychain

However, the result of security default-keychain is always /Library/Keychain/System. I can only change the system default with sudo

Has anyone been able to work though a similar issue? I've found a lot of similar or outdated issues, but they all point to things like "use setup_ci" or unlock the keychain, but I think the crux of the problem here is the inability to change the default keychain.

Alternatively, I'm able to see valid certs with

security find-identity -v -p codesigning mykeychain

but unable to see them with

security find-identity -v -p codesigning

Is there a way for me to get xcodebuild to use the specific keychain?

To Reproduce
See above

Expected behavior

$ security default-keychain mykeychain
$ security default-keychain
/path/to/mykeychain

Runner Version and Platform

OSX - tar xzf ./actions-runner-linux-x64-2.165.2.tar.gz

@jl-gogovapps jl-gogovapps added the bug Something isn't working label Mar 1, 2020
@TingluoHuang
Copy link
Member

@jl-gogovapps can you share a YAML file with what you are trying to run? can you make your script work in a bash shell without the runner involved?

@TingluoHuang TingluoHuang added the question Further information is requested label Jun 6, 2020
@raphaelcruzeiro
Copy link
Contributor

I'm experiencing this issue as well @TingluoHuang. What is interesting here is that this works the first time I install the the runner but stops working after the machine is rebooted (reinstalling the runner makes it work again).

When the problem starts occurring, security default-keychain returns only the system keychain if it's being ran by the runner. If I ssh to the machine under the same user, security default-keychain returns the correct keychain. The only workaround I found so far is to reinstall the runner.

raphaelcruzeiro added a commit to raphaelcruzeiro/runner that referenced this issue Dec 5, 2020
Without creating a session, the service is not able to access the keychains for the user specified under `UserName`. This causes any workflow that deals with code signing to fail as the only keychain loaded with be the system one. This should fix actions#350
@sebalopez
Copy link

Hi, I am facing this exact issue but for me it only started after the recent MacOS upgrade to 10.15.7 - this was actually working fine for me with the runner running as a service up until a couple weeks ago.
Are there any news on merging this PR?

@jl-gogovapps
Copy link
Author

i ran into issues with keychains recently, they are really hard to debug, and there are many similar stackoverflows - the issue was one of the two WWDR certs missing.

Make sure you have:

WWDR Certificate (Expiring 02/07/2023 21:48:47 UTC)
WWDR Certificate (Expiring 02/20/2030 12:00:00 UTC)

from https://www.apple.com/certificateauthority/

@sebalopez
Copy link

I read elsewhere on SO having only the latest should be enough, though it in any case its emission last month seems to be related to this issue. Devilishly hard to debug indeed.

TingluoHuang pushed a commit that referenced this issue Oct 6, 2021
Without creating a session, the service is not able to access the keychains for the user specified under `UserName`. This causes any workflow that deals with code signing to fail as the only keychain loaded with be the system one. This should fix #350
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
4 participants