Add support for xcsigningtool

[keith]

With Xcode 11 Apple quietly added a new tool called xcsigningtool that allows you to sign an app without adding the certificate to the global keychain. Usage:

% xcrun xcsigningtool
Usage:
xcsigningtool sign -path <binary_path> -certificate <certificate_path> [-entitlements <entitlements_path>]

I think adding support for this where you could specify the path to a certificate as an attribute of the rules that require it would be a huge win for hermiticity and simplicity

[allevato]

We discussed this and it's unlikely that we'll add support for it. I think "huge win" is a overselling it a bit 🙂

As long as I'm understanding the usage correctly, if Bazel is launching a hermetic action with the certificate file provided as an attribute (or as a command-line argument, if we wanted to do it that way), the file would have to be present in the workspace. That's potentially risky if it means the certificate needs to be checked into source control, because then the certificate is always going to be present in the history.

Perhaps one could imagine putting the certs in something other external location and then using an external repository or custom repository rule to download them, but that still has concerns about the security of those certs as they go from one end of the process to the other, and how they're sitting around on in the workspace's external folder after they've been downloaded.

On the other hand, the current workflow doesn't have these issues—the certificate is in secure storage on the developer's machine, and uses a tool that specifically accesses that secure storage without any other middlemen.

(Personally I'd like for us to get the build rules out of the code signing business more or less entirely, or at least delegate it to a specific archiving rule meant for exporting an app for distribution and otherwise leave signing up to the consumer that needs it (e.g., an IDE that plans to run the app), but I don't think that's entirely feasible and would probably complicate existing workflows more than the benefits we'd get so the time to consider that has likely passed.)

[jerrymarino]

Would love to see this 👍 . The current status of using the keychain can introduce a lot of real world issues, when attempting to manage it out of band.

I like the idea of abstracting out the codesign commands and that'd give rules_apple more flexibility to supply the behavior w/o forking.

From a security perspective, we might be able to come up with a rule and pattern that

• requires the user to encrypt the cert
• provide the bundling rule a passphrase to decrypt certs, perhaps in memory.

[shepting]

We are thinking of using something like Age (https://github.com/FiloSottile/age) to encrypt secrets (keys and certificates) in the repo. That would leave the public key and secrets checked-in, but with the private key only on CI machines. That would ameliorate the downsides of checking the files into the repo and would still give excellent security.