Closed kornelski closed 2 years ago
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).
Yes, please!
I'll open a bug up for that to track status!
Using swift-argument-parser requires Swift 5.1, so that's unfortunately not feasable at the moment. 🙁
(See #1583)
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.
Any updates on this? What is the current best practice for using sign_update
on CI?
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.
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.
Created a PR to address the issue: https://github.com/sparkle-project/Sparkle/pull/1836
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.
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.
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.