Implement macOS code signing and notarization

[pietroalbini]

Code signing and notarization are becoming crucial to ship software to macOS, but we currently neither codesign nor notarize Rust releases. We should ensure that all binaries we ship do both, to avoid our users getting warnings or being unable to run the compiler.

This is trickier than just calling the Xcode CLI though. Our release process roughly works this way:

• rust-lang/rust's CI produces full release artifacts for all the platforms we support for every PR we merge. Those artifacts are uploaded to an S3 bucket and kept there for around 160 days (allowing PR-by-PR bisection).
• When a release starts, promote-release fetches the artifacts for the latest commit on the master, beta or stable branch (depending on which channel we're releasing), signs everything with GPG, generates the manifests and uploads everything to static.rust-lang.org.

The main problem is where we should run codesigning and notarization: CI is not trusted enough to have the developer certificates and credentials in it, and the release process runs on Linux. Apple's tools to codesign and notarize instead only work on macOS, preventing us from just running them during promote-release.

The idea me, @Mark-Simulacrum and @kinnison had a bit ago is to develop a separate HTTP service that runs on a persistent Mac Mini somewhere. The release process would upload the binaries to the Mac Mini, which would sign them and send them back to the release process. The HTTP service would also need to ensure the binaries come from a trusted source.

[lfacchinelli]

@pietroalbini Wouldn't be easier for the mac to just pick up from a defined location (i.e : s3) sign it and notify the release process that signing is completed, instead of moving binaries between components?
In that way, binaries will only live in s3, mac mini will have the required certs and we have a good security control of who/what/when can access the S3 repository

[pietroalbini]

Yes, that would also work! I'm thinking something like this:

1. The release process gives the mac mini a list of tarballs and .pkgs to sign
2. The release process downloads them from S3, signs them and stores them locally
3. The release process polls the mac mini waiting for the signing to be done, and then downloads the signed binaries from the mac mini directly

I'm not sure it's worth changing the third step to have the mac mini upload the signed binares directly to S3, as the release process would then need to download them back to do the following processing steps (recompressing tarballs in different formats, gpg-signing them, generating the manifests...).

[lfacchinelli]

Changing step 3 might be an extra effort in complexity but as a tradeoff, I think in that way we can avoid dealing with authentication/security on the mac (ensure the binary is pulled by the right release process, etc)

Thoughts about that?

[pietroalbini]

Hmm, to ensure we're on the same page, what would be the interactions between the release process and the signing server you envision?

[lfacchinelli]

It’d be something along the lines of:

• release process build binary and upload to S3
• release process hits signing endpoint and waits for a response
• Signing process receives request and picks up from s3 the binary, signs and upload the signed binary
• Signing process return status to release process and based on that status the release process continues (or fail)