bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.
Please report any other irregularities here.
Simple storage is private to extension, so it needs some way to namespace the data it stores per extension. The point is that it's as foolproof and easy as possible to use, so we don't want to ask the developer to do it. I don't know how that would work under the reboot, but it at least involves the module's having a handle to information about the extension it's being used in.
Ok, I just talked to Brian Warner, who will be writing up a JEP for Jetpack IDs. The basic notion is that, like Chrome Extensions, the unique ID of a Jetpack will ultimately be a public key (or a public key's fingerprint), which will ensure that a Jetpack can't be spoofed. For now, though, in part because we don't have the time or the tools, we're just going to have a Jetpack's "id" be either a random number or some developer-chosen value, similar to an extension ID. We'll provide you with a way to access this shortly, but we need to make developers aware that this ID won't be "forwards-compatible": once we figure out an algorithm for keypair generation and get the tooling down, Jetpack developers will eventually need to migrate to using an unspoofable ID, at which point they won't be able to upgrade extensions with spoofable IDs. This sucks, but it's the only way we can really think of managing this change right now. Brian's upcoming JEP will be laying out the full roadmap for this. If it contradicts my comment here in any way, please prefer his JEP over my comment.
As for getting the ID of a Jetpack-based extension: currently packaging-related metadata and methods can be obtained through the 'packaging' global that comes with any Jetpack-based CommonJS module: https://jetpack.mozillalabs.com/sdk/0.1/docs/#guide/globals We could add a 'packaging.id' that contains the ID of the extension; right now this would just be the extension's ID, but eventually it would be the extension's public key/fingerprint. Would that be acceptable?
Thanks, that would work, but now I'm wondering whether we should delay simple storage until this is sorted out. I don't like the idea of basing an API's implementation on a hack that will break forward compatibility in what's supposed to be a production-ready SDK. Is there any way to guarantee forward compatibility, which I guess would mean providing us with a mapping from old ID to new when the time comes?
FYI, the draft JEP118 is up at https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/118
After the discussion at the Jetpack meeting yesterday, it sounds like we are going to follow adw's advice from comment 3 and delay simple storage until this is sorted out. In particular, this won't be sorted out until we've determined a well-defined asymmetric cryptography algorithm for creating key-pairs, and for serializing the public key (or its fingerprint) in a form that can be used as an extension ID. I'll make bugs for these soon.
Just created bug 553020. It should be noted that it's not actually a hard blocker for this bug, since for the time being, it's possible to just use the extension's actual extension ID--it's just that this isn't forwards-compatible, since we'll eventually be requiring that these IDs be unforgeable.
I think we should define the "how does jetpack code learn its extension ID" API in parallel with the "how will we compute the extension ID" effort. I'm comfortable stating that the extension ID will be an ASCII string of no more than 100 characters, confined to letters, numbers, and a few punctuation marks (".,-", should be enough). Development of the code for this bug is blocked on the first effort, but not on the second. *Deployment* of the code developed for this bug may well be blocked on the second (and upon the tools to create the signing keys, and hash them into an extension ID).
So would it make sense to have this bug be renamed to: "Add a 'packaging.id' global that returns the ID of the extension in which the CommonJS module is loaded?" packaging.id would just be the extension ID--that is, whatever the arbitrary developer-set "id" property of the extension's package.json is, which is mirrored in the extension's install.rdf. Once we figure out bug 553020, though, we would basically require that the package.json's "id" property be the unforgeable ID we settle on. Implementing 'packaging.id' this way would be super straightforward.
I changed the title slightly to refer to IDs instead of metadata. The particular implementation you describe sounds fine. I also went ahead and marked this bug as dependent on bug 553020 to signify that landing/deployment of this bug's fix should depend on having locked-down IDs, as comment 7 mentions. Feel free to change that if you think we should land this beforehand and just warn people that IDs will be changing.
Depends on: 553020
Summary: Modules need a way to access metadata of the extensions that load them → Modules need a way to access the IDs of the extensions that load them
Looks like this won't be provided by packaging.id, but rather by require("self").id, as mentioned in bug 557663 comment 1. I noticed this is tagged as P1 critical for 0.3... Is that still the case, since simple storage isn't slated for 0.3?
As I understand it, the primary reason we couldn't get Simple Storage for 0.3 is that this bug wasn't fixed. If we didn't fix this for 0.3, we'd have to fix it very early in the 0.4 cycle in order to make sure we had enough time to implement Simple Storage in that cycle. So I'd prefer to see this land in 0.3, although I'm willing to reconsider if we can come up with a credible plan for unblocking Simple Storage early enough in the 0.4 cycle.
+1 to getting this in 0.3, because it blocks implementation of the Lifecycle module as well. I tried emailing Brian directly about status on this, and didn't get a response.
Oh. Well, I should clarify that the "hard" blocker for actually letting developers *use* the Simple Storage API in a forwards-compatible/futureproof way is bug 553020, because using an unforgeable ID is the only way we can guarantee forwards compatibility. Resolving *this* bug (i.e., bug 548870) is relatively simple in comparison--it just wouldn't be future-proof, b/c we'd be handing the client whatever the effective install.rdf's em:id of the extension is (i.e., a GUID or email address).
It doesn't look like this is going to land for 0.3. However, last week Brian and I talked through a plan for unblocking Simple Storage early in the 0.4 cycle while work continues on unforgeable IDs (bug 553020), upon which this bug depends. I think Brian is going to run that plan by Drew to make sure it really does unblock Simple Storage, after which he'll start working on it. Watch bug 553020 for its progress.
Target Milestone: 0.3 → 0.4
Just realized this bug is a subset of bug 557663. Marking it as duplicate since that bug makes it possible to access an extension's ID via 'require("self").id'.
Assignee: avarma → nobody
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 557663
The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product. To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.