Security/Reviews/ModuleLoader: Difference between revisions
Jump to navigation
Jump to search
Full Query
(Created page with "{{SecReviewInfo |SecReview name=Module Loader }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }}") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{SecReviewInfo | {{SecReviewInfo | ||
|SecReview name=Module Loader | |SecReview name=Module Loader | ||
|SecReview target=<bugzilla> | |||
{ | |||
"id":"756491,743359" | |||
} | |||
</bugzilla> | |||
}} | |||
{{SecReview | |||
|SecReview feature goal=* we are using a module loader that is similiar to what is used by Node.js | |||
** long term goal is to land SDK to Firefox | |||
** landing this first, then api then sdk | |||
* this would allow jetpack items to use the module loader (currently shipped with each add-on) | |||
** Loader instance won't be shared across add-on instances just a code to create loaders | |||
** Blacklists Components from sandboxes we create | |||
https://bugzilla.mozilla.org/show_bug.cgi?id=747434 | |||
** We will be able to visualize capabilities graph for add-on reviewers like this: | |||
http://bl.ocks.org/2582184 | |||
|SecReview alt solutions=* keep it as is | |||
|SecReview solution chosen=* better for performance and smaller add-ons | |||
|SecReview threats considered=* uses SubscriptLoader() so remote modules will not be loaded. | |||
}} | }} | ||
{{SecReviewActionStatus | {{SecReviewActionStatus | ||
|SecReview action item status=None | |SecReview action item status=None | ||
}} | }} | ||
Latest revision as of 13:55, 29 May 2012
Please use "Edit with form" above to edit this page.
Item Reviewed
| Module Loader | |||||||||||||
| Target |
2 Total; 0 Open (0%); 1 Resolved (50%); 1 Verified (50%); |
||||||||||||
{{#set:SecReview name=Module Loader
|SecReview target=
| ID | Summary | Priority | Status |
|---|---|---|---|
| 743359 | Land module loader to firefox | P1 | RESOLVED |
| 756491 | SecReview: Land module loader to firefox | -- | VERIFIED |
2 Total; 0 Open (0%); 1 Resolved (50%); 1 Verified (50%);
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- we are using a module loader that is similiar to what is used by Node.js
- long term goal is to land SDK to Firefox
- landing this first, then api then sdk
- this would allow jetpack items to use the module loader (currently shipped with each add-on)
- Loader instance won't be shared across add-on instances just a code to create loaders
- Blacklists Components from sandboxes we create
https://bugzilla.mozilla.org/show_bug.cgi?id=747434
- We will be able to visualize capabilities graph for add-on reviewers like this:
What solutions/approaches were considered other than the proposed solution?
- keep it as is
Why was this solution chosen?
- better for performance and smaller add-ons
Any security threats already considered in the design and why?
- uses SubscriptLoader() so remote modules will not be loaded.
Threat Brainstorming
' {{#set: SecReview feature goal=* we are using a module loader that is similiar to what is used by Node.js
- long term goal is to land SDK to Firefox
- landing this first, then api then sdk
- this would allow jetpack items to use the module loader (currently shipped with each add-on)
- Loader instance won't be shared across add-on instances just a code to create loaders
- Blacklists Components from sandboxes we create
https://bugzilla.mozilla.org/show_bug.cgi?id=747434
- We will be able to visualize capabilities graph for add-on reviewers like this:
http://bl.ocks.org/2582184 |SecReview alt solutions=* keep it as is |SecReview solution chosen=* better for performance and smaller add-ons |SecReview threats considered=* uses SubscriptLoader() so remote modules will not be loaded. |SecReview threat brainstorming=' }}
Action Items
| Action Item Status | None |
| Release Target | ` |
| Action Items | |
| ' | |
{{#set:|SecReview action item status=None
|Feature version=` |SecReview action items=` }}