Key management improvements

[kornelski]

We've had several questions about the new Keychain-based key management.

• How to back up the keys? (backup login keychain, or find Sparkle's item in in and backup that)

• How to share the keys with other team members? (don't share them, as it's needed to sign a release, not for development. If you have to, share a keychain).

• How to use the keys in CI? (the copy the key from keychain and pass it as argument in generate_appcast)

• How to use multiple different keys for different projects? (not recommended, but if you have to, copy keys and pass them as argument to generate_appcast)

---

However, this is not very elegant.

The tools for generating keys and signing need to be better documented, at least have proper argument parsing and have --help.

The tools should also support separate key per bundle ID (e.g. look up a key for the bundle, and fall back to "global" one if not found).

There needs to be a proper export tool, so that people don't have to copy'n'paste stuff from the keychain.

[Wevah]

I'm up for rewriting parts of the Swift helper tools to use swift-argument-parser if that'd be useful (it's much nicer than manually parsing arguments).

[kornelski]

Yes, please!

[Wevah]

I'll open a bug up for that to track status!

[Wevah]

Using swift-argument-parser requires Swift 5.1, so that's unfortunately not feasable at the moment. 🙁

(See #1583)

[Wevah]

467687e670d96554ed121ee3c416fa468c1fc956 (part of the branch for #1608) adds an --export/-e flag that will copy an already-generated key to a new keychain. I will probably add another option to simply generate a new key into a stand-alone keychain also.

[jaroslavas]

Any updates on this? What is the current best practice for using sign_update on CI?

[zorgiepoo]

generate_appcast has a flag to take signing key as an argument. Otherwise you may be able to import the signing key to the keychain (generate_keys has options to export and import keys from/to keychain) which allows you to use sign_update against it.

sign_update does not have a flag to take a signing key like generate_appcast does but that's probably just an omission. It would rather also be nice to adopt all these tools to use swift argument parser before extending them further. #1608 PR is now somewhat out of date.

[jaroslavas]

Yes, I'm able to add key to the keychain, but even if the keychain is unlocked sign_update asks for a keychain password by throwing modal (twice), which is a no go for CD machine.

[jaroslavas]

Created a PR to address the issue: https://github.com/sparkle-project/Sparkle/pull/1836

[zorgiepoo]

Tentatively tagging any feasible keychain improvements for 2.1.

The tools for generating keys and signing need to be better documented, at least have proper argument parsing and have --help.

We have proper command line parsing now.

There needs to be a proper export tool, so that people don't have to copy'n'paste stuff from the keychain.

We can export/import keys now from generate_keys and have documentation (both on website and in the tool's -h) that explains this.

The tools should also support separate key per bundle ID (e.g. look up a key for the bundle, and fall back to "global" one if not found).

This is a good idea to address as part of #1969.

I think we need to move away from the notion of using separate keychains or managing keychains too much. Last I checked these APIs for using separate keychains have been deprecated or marked as being unsupported pretty recently. Being able to use the iCloud Keychain (#2029) would be better, but it turns out to be a little complicated.

[zorgiepoo]

We support multiple keys now as part of #1969. Closing as I believe there are no other addressable points at this time, or they can be tracked separately.