654588 - remove cryptographic JIDs

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect)

Description

[Brian Warner [:warner :bwarner]]

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

Comment 1

[Brian Warner [:warner :bwarner]]

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.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

+        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

Comment 3

[Brian Warner [:warner :bwarner]]

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!

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Cherry-picked commit to 1.0b5 branch:

https://github.com/mozilla/addon-sdk/commit/fceae1bb71cfea631a974d1ea068a91377ac3d44