Xcodebuild Archive fails to errSecInternalComponent in GitHub Action

Hi!

I have an issue to build Archive when using xcodebuild in GitHub Action workflow. The project s quite basic iOS project. Archiving works fine locally using command

xcodebuild -quiet -workspace MyProject.xcworkspace -scheme "MyProject Release" clean archive -configuration release -destination=generic/platform=iOS -archivePath MyProject.xcarchive

Same command via SSH gives an error

errSecInternalComponent. Command CodeSign failed with a nonzero exit code

IF I run a command security unlock-keychain beforehand, then creating .xcarchive passes.

In Keychain Access, I have necessary certificates. Those are located in login.keychain and every certificate seems to be valid.

Also, based on this answer, I have tried to put 6 different Apple Worldwide Developer Relations Certification Authority -certs in System.keychain and removed same stuff from login.keychain. This didn't bring solution either.

Our GitHub (Enterprise) Action workflow is quite simple (here is an extract):

name: Build_Tests
on:
  push:
    branches: 
        - 'GHA_tests'
  workflow_dispatch:

jobs:
  build:
    runs-on: [ self-hosted, macos-1 ]
     .....
      - name: Archive
        shell: bash
        run: |
          xcodebuild -quiet -workspace MyProject.xcworkspace -scheme "MyProject Release" clean archive -configuration release -destination=generic/platform=iOS -archivePath MyProject.xcarchive

In our CI/CD environment is a stack of Macs with latest macOS, and every those has a unique password, so embedding "security unlock-keychain" with password is not a (good) solution. If it is only one to get our build and test environment to work, then we have to start to live with it, but I would love to get some other solution to work. Easiest for us would be that old workflows, with example above, continues to work. I mean that just using commands like "xcodebuild" would work like a charm.

I have also run through this excellent post by eskimo and seems like that certificates are fine. No issues found. Locally run security find-identity -p codesigning gives  in "Matching identities" "4 identities found" and in "Valid identities only" "4 valid identities found". Also, I can run codesign -s "Apple Development" -f "MyTrue" for my certificates four time in a row with success. (We have four certificates, yes. There is one dev for in-house, one for public, one Distribution and an old iPhone Distribution from...past.)

Also, each 4 certs in login.keychain has in Access Control "Confirm before allowing access" selected and in the list "Always allow access..." there is at least a tools codesign and Keychain Access. Apple Distribution cert's Key has four "Always allow..." apps: Keychain Access, Xcode, codesign and productbuild. These certificates are imported to Keychain Access using commands

security unlock-keychain -p <keychain password> login.keychain
security import <certificate file>.p12 -k login.keychain -P <cert password> -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k <keychain password>

Via SSH I have run command codesign -s and it gave similar issues than in eskimo's example: "MyTrue: errSecInternalComponent". A command security unlock-keychain naturally fixed this. The problem here is that I can't include passwords in CI after unlock-keychain command.

Any ideas what I am doing wrong? My guess is that I am not a far of working solution, but just can make in my mind what I am doing wrong atm. I think that I have tried about everything during these two weeks when wondering this issue. I appreciate everyone who reads this posts and specially you who posts a working solution :)

-Harri

Add a Comment

Replies

About those certificates.

If I go to Developer Apple's Certificates list page and start to create a new one (from + ), in the end of the page is links for four different certificates

Worldwide Developer Relations Certificate Authority (Expiring 02/07/2023)

Worldwide Developer Relations Certificate Authority (Expiring 02/20/2030)

Worldwide Developer Relations - G4 (Expiring 12/10/2030)

Developer ID - G2 (Expiring 09/17/2031)

Are those four only needed certificates in CI/CD machines or should I install some extras from https://www.apple.com/certificateauthority/? Newer ones?

-Harri

There are two preconditions for being able to use a key stored in a file-based keychain:

  • The keychain must be unlocked (A).

  • The caller must satisfy the key’s ACL (B).

It sounds like you’re monkeying around with B hoping that it’ll fix A. It won’t. You must unlock the keychain.

One option here is to put the code signing identity in an additional keychain, giving it the same password across all your machines, and unlock that. However, that adds a bunch of extra complexity. Honestly, I think you’d be better off fixing this:

In our CI/CD environment is a stack of Macs with latest macOS, and every those has a unique password

If you have a cluster of machines that are essentially identical, there’s not much benefit to given each one a unique password.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yep. Unifying CI/CD machines and adding single line into workflow files solved this issue.

- name: Init
  run: |
    security unlock-keychain -p $PASSWORD

This is not probably the smoothest way to handle this, but we can live with this.

Thanks!

-Harri