Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting EdDSA signatures for multiple projects #1969

Closed
digitalmoksha opened this issue Oct 2, 2021 · 3 comments · Fixed by #2074
Closed

Supporting EdDSA signatures for multiple projects #1969

digitalmoksha opened this issue Oct 2, 2021 · 3 comments · Fixed by #2074
Milestone

Comments

@digitalmoksha
Copy link
Contributor

I'm working on migrating to EdDSA signatures. But I got to thinking about how to support multiple apps on one machine.

As far as I can tell, generate_keys can only generate one key in the keychain, which is named Private key for signing Sparkle updates. Which means I can't have two different keys, say one for Org A and one for Org B. And although you can export the key to a file, it can only export that one key

generate_appcast supports specifying the key string through the -s option. Which would work for multiple organizations assuming I could get two separate keys generated with generate_keys. Seems like that would require creating and then exporting the first key, delete it from the keychain, and then create/export the second key. And then I definitely have to keep the private key stored somewhere, not in the keychain.

What about allowing an option on generate_keys to set the key name/title of the key to generate. Then the first key could be generated with -n "Org A private Sparkle signing key", or `-n "myApp signing key" or whatever.

generate_appcast would of course need to accept the same parameter. But then you can leave the keys in the keychain, and still specify which one you're using for your app.

@zorgiepoo
Copy link
Member

zorgiepoo commented Oct 2, 2021

I'm working on migrating to EdDSA signatures. But I got to thinking about how to support multiple apps on one machine.

I think Kornel intended it so that you use the same EdDSA key for multiple apps, at least in the same Org. This is like using the same Apple Developer ID for multiple apps. Let's say you want to use a different Developer ID for multiple orgs which is analogous to here; I guess you then just pick a different cert.

What about allowing an option on generate_keys to set the key name/title of the key to generate. Then the first key could be generated with -n "Org A private Sparkle signing key", or `-n "myApp signing key" or whatever.

generate_appcast would of course need to accept the same parameter. But then you can leave the keys in the keychain, and still specify which one you're using for your app.

Not a bad idea. However we have also had requests to specify the keychain to use rather than key name/title in the default keychain. I think this was partially attempted in #1608 and I believe generate_appcast currently supports specifying the keychain for DSA. Developers could potentially share a non-default keychain with other developers in the same org, so this might be preferable. For this feature enhancement, we'd have to pick which way we'd want to go with.

@digitalmoksha
Copy link
Contributor Author

Let's say you want to use a different Developer ID for multiple orgs which is analogous to here; I guess you then just pick a different cert.

Yes, the Apple certs are usually tied to a person or organization, and then you can specify which cert to sign with. Multiples can exist in the same keychain.

I suppose you could use multiple keychains, though I'm not as fond of that idea. But that's probably because i'm not a big keychain user 😄

@zorgiepoo
Copy link
Member

I agree, I think adding a key/title option to generate_keys, sign_update, and generate_appcast would be simpler. It may have to be something other than -n, you'd need to check it doesn't conflict with any existing flag. Otherwise feel free to make a PR for these three tools if it unblocks you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants