Jetpack currently creates and maintains an ECDSA keypair for each addon, and uses the public verifying key to derive the addon's unique ID (the "JID"). There is just enough code in the SDK to create these keys and to prod the user to copy them when it detects that they're missing. The private key is stored in ~/.jetpack/keys/$JID along with the pubkey and some metadata. We don't yet have a story for actually using these keys. There are some interesting security things that can be done when each addon has a well-known key (https://forums.mozilla.org/addons/viewtopic.php?f=27&t=2939&sid=674a50a331b533d1403c978eee25d481 is the start of a discussion), so I planned for this early. Perhaps too early. There are a couple of problems with having these keys around: 1: developers are slightly hassled by reminders to copy the private key around when they move the source to a new computer, or to delete the JID from package.json to allow a new key to be generated 2: validating the ~/.jetpack data takes a second or two, which slows down the "preflight" check that runs as part of XPI generation 3: FlightDeck will need to do whatever signing operations the SDK does. So developers who upload their SDK-developed XPI to continue development on FlightDeck will also need to upload that XPI's private key. Likewise, developers who start on FlightDeck and "unplug" to work locally on the SDK will need to download the FlightDeck-generated private key for their addon. (the alternative is to decouple the JID of an addon created by the SDK from the JID of that "same" addon in FlightDeck). 4: asking developers to maintain private keys safely, especially the new developers that jetpack is courting, is perhaps too great of a burden So, as eager as I am to have strong security properties for Jetpack, I'm going to propose that we rip out the crypto and generate simple boring non-cryptographic random GUIDs for each addon, and that we do this in 1.0b5 to shake out any problems that result before 1.0 . The downsides of doing this: 1: if/when we reintroduce signatures, then existing addons which want to benefit from them will either need to change their JIDs (probably complicating their upgrade process), or we'll have to settle on using less-secure non-JID-bound pubkeys (introducing the question of "which key should be signing this addon", weakening the design) 2: the usual risk of code changes at the end of a dev cycle
https://github.com/warner/addon-sdk/tree/654588-nocrypto has the branch with everything cleaned out. The preflight step is still present, but if it sees a missing "id" field then it generates a random JID of the form "jid1-XYZ@jetpack", where XYZ is 14 characters of base64-2 (base64 but with A and B instead of + and /). Addons which have a jid0- id continue to use them, but the preflight check does not look for a private key, nor does the check assert anything about the id it sees.
+ print >>stderr, ("No 'id' in package.json: creating a new id for you.") ... + self.failUnlessEqual(out.getvalue().strip(), + "No 'id' in package.json: creating a new id for you.") Nit: (the second occurrence in each string of) id -> ID --ECDSA code :-( Otherwise great. r,a=myk
Landed in https://github.com/mozilla/addon-sdk/commit/f6f3a5d5741440a6052250d9f4284adde3a93c23 , should be cherry-pickable onto 1.0b5 /me raises a toast to the deleted code. Fare thee well, ECDSA!
Cherry-picked commit to 1.0b5 branch: https://github.com/mozilla/addon-sdk/commit/fceae1bb71cfea631a974d1ea068a91377ac3d44