Open Bug 761810 Opened 12 years ago Updated 10 years ago

SecReview: Simplify signing XPIs in Jetpack

Categories

(mozilla.org :: Security Assurance: Review Request, task)

Product:
mozilla.org
Component:
Security Assurance: Review Request
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: curtisk, Assigned: dveditz)

Details

SecReview tracking bug
Actions regarding the review of the dependent bug should be tracked here.

Feature Page: 
https://wiki.mozilla.org/Simplify_or_automate_signing_of_Jetpack_XPIs

1) Who is/are the point of contact(s) for this review?
2) Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):
3) Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:
4) Does this request block another bug? If so, please indicate the bug number
5) This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?
6) To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list?  If so, which goal?
7) Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)
7a) Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?
7b) Are there any portions of the project that interact with 3rd party services?
7c) Will your application/service collect user data? If so, please describe
8) If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):
9) Desired Date of review (if known from https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html) and whom to invite.
We have not started working on this idea - nor is it a high priority at the moment. Thus, it would probably be premature to try to do a sec-review for this. 

Not sure what your usual process is in this case: close, etc - will let you take care of that if that's ok
No worries, we mark stuff as soon as we find it and the bug sits around until you all decide to move forward or move on.
Priority: -- → P5
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy][needs info]
Assignee: dcm → jgriffiths
Flags: needinfo?
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy][needs info] → [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy]
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy][Fx]
Assignee: jgriffiths → nobody
Flags: needinfo?
Priority: P5 → --
Flags: needinfo?
:dveditz - does https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit?pli=1 supercede this work /idea?
Flags: needinfo? → needinfo?(dveditz)
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy][Fx]
(In reply to Curtis Koenig [:curtisk] from comment #3)
> :dveditz - does
> https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-
> KrPxLoZFM3mWmEmOses/edit?pli=1 supercede this work /idea?

I'm not sure, not automatically. What is being signed here is the update information hosted on a insecure web site. Even if we require the add-ons themselves to be signed it's still a problem if you host the update XML file insecurely -- a tampered one could point at a different add-on altogether. If people persist in self-hosting on non-SSL sites then we still need this mechanism.
Flags: needinfo?(dveditz)
assigning to dveditz as he's likely the resource with the most knowledge on this
Assignee: nobody → dveditz
You need to log in before you can comment on or make changes to this bug.