Sparkle

Suggestions for managing the private key for an open-source project?

Asked by Steve Voida

Hi Andy and company,

Now that Sparkle requires signed code, can anyone offer a recommendation about good strategies for handling the private key in the context of an open-source project? My gut instinct is that the private key should remain at least semi-private (e.g., posted in the SSH space on SourceForge that only approved developers can access) so that I can provide the users some piece of mind that Sparkle is only picking up project-sanctioned updates. On the other hand, it *is* a project that I want others to be able to pick up and use, so locking the key away also seems sub-optimal.

Does anyone else have a good solution for what to do in this case? Any suggestions would be greatly appreciated.

Best,
Steve

Question information

Language:
English Edit question
Status:
Solved
For:
Sparkle Edit question
Assignee:
No assignee Edit question
Solved by:
Andy Matuschak
Solved:
Last query:
Last reply:
Revision history for this message
Best Andy Matuschak (andymatuschak) said : 		#1

Ooooh, that's a tricky question. You could ask Transmission or Cyberduck or Adium what they do, but here's what I'd do:

Whoever makes releases (ie: packages your release, updates your project's homepage) should have the private key. If someone wants to fork your project, they can generate a new keypair for their fork's updates.

Revision history for this message
Steve Voida (svoida) said : 		#2

Thanks Andy Matuschak, that solved my question.