Support App Store Connect API keys and provisioning profiles

[chris-araman]

Closes #71.

Using an App Store Connect API key with Xcode >= 13 allows automatic device registration, certificate creation, and provisioning profile creation.

Users who want to use an existing provisioning profile, or who use Xcode < 13, can now pass a list of Base64-encoded Mac or iOS provisioning profiles.

[chris-araman]

❌  error: Revoke certificate: Your account already has an Apple Development signing certificate for this machine, but its private key is not installed in your keychain. Xcode can create a new one after revoking your existing certificate

Looks like I may need to make use of actions/cache.

[mxcl]

We should bump to v2 since we are removing code-sign-certificate.

Unless we can reasonably prove this only effects <2 projects. (Not sure we can prove anything).

[chris-araman]

I'm not planning to remove any inputs. I reorganized the README section on code signing a bit:

• App Store Connect API key: Requires Xcode 13. Manages device registration, certificates and provisioning profiles automatically.
• Certificates: Installs a specific certificate to the macOS Keychain.
• Provisioning Profiles: Installs specific provisioning profiles.

None of these should be mutually exclusive, in theory. The simplest usage for most users should be the API key alone.

To Do:

• Figure out how to address the private key is not installed error.
  • We could find a way to persist the certificate for a given GitHub Actions host (macOS Device UUID), perhaps using @actions/cache. What are the security implications of that?
  • Alternatively, we could call the App Store Connect API directly to revoke the existing certificate beforehand. This might have the effect of generating a long list of revoked certs on the developer's account.
  • Failing those ideas, maybe this is only useful for GHES and self-hosted runners? That would be disappointing.
• Determine whether installing a Mac .provisionprofile is useful, or if only iOS-ish .mobileprovision profiles are useful. It's not clear to me, for instance, if a provisioning profile from a developer's Mac is meant to (or can) be copied to another Mac and remain useful. Mobile profiles clearly seem useful, as there are dozens of projects copying them around, and GitHub documents how to install them.
  • Perhaps a .provisionprofile is only useful for Mac Catalyst development? I that's the case, I'll document it as such.

[mxcl]

Safely additive.

[chris-araman]

Sorry for the delay. It's been, uh, an unexpectedly busy few weeks. 😅

Still investigating the To Dos above.

[mxcl]

nps dude; to me you’re an open source king 👑

[chris-araman]

I think I've convinced myself that the propagation of provisioning profiles is generally useful.

Unfortunately, I think the App Store Connect API functionality is only useful for self-hosted runners, where private keys persist. Would you be comfortable accepting this PR in order to support the functionality only for self-hosted runners?

Support for GitHub-hosted runners could be added in a later PR by persisting any private keys installed using the App Store Connect API. I want to err on the side of incremental progress, and I worry about letting this PR die on the vine.

[mxcl]

Possibly the private key could be written to the repo as a secret?

Either way that can happen later. It’s fine that this only works for private runners provided we document it as such.

[chris-araman]

Sounds good. I'll add some clarifying documentation to the README and YAML, then merge. Probably tonight or tomorrow. I can (minor) release, too, if you like.

[chris-araman]

Possibly the private key could be written to the repo as a secret?

Ooh, that's a neat tack. I think it'd still be one private key per Device UUID, but that could be included in the secret name.

[mxcl]

Yep please bump too!