Closed
Bug 1232311
Opened 9 years ago
Closed 5 years ago
Show `${name} submitted by ${submitter}` in installation doorhanger for signed add-ons
Categories
(Toolkit :: Add-ons Manager, defect, P4)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox45 | --- | affected |
People
(Reporter: ma1, Unassigned)
References
Details
(Whiteboard: triaged)
User Story
Sorry for the bug-spam, accidentally hit [Enter] while still typing bug title, damn. The story: 1. We don't allow authors to sign their extensions anymore with their own code signature 2. The only guarantee we can make for signed add-on is that they've been submitted by an AMO account 3. We can and should, therefore, provide this information upon installation in an useful an unambiguous way (also because Chrome does provide per-developer signatures) I think we should suport an optional manifest field, e.g. "submitter", which should be subject to the following restrictions, enforced upon signing: a) Unique across authors in the AMO DB b) Requires mandatory review upon first usage and any changes c) ASCII characters only to prevent Unicode homographic spoofing (not sure about this given [b]) Should I file a "Support and validate 'submitter' field" dependency in the Add-on Validation component for the restrictions above?
Comment hidden (off-topic) |
Reporter | ||
Updated•9 years ago
|
User Story: (updated)
Summary: Show `${Add-on name} submitted by [Author Name]" → Show `${name} submitted by ${submitter}` in installation doorhanger for signed add-ons
Comment 1•9 years ago
|
||
I don't think we need (b) in this way. What we need to verify before signing is just that the developer can justify the value in the 'submitter' field.
We could have an option in the user management pages, where the user can request a submitter value, with a justification. An admin evaluates it and assigns the submitter value if everything's okay, and then the developer can use it. If a developer submits a version with an unassigned or incorrect submitter, it's auto-rejected with an explanation of how to request it. This way we separate it from the review process, which is already overburdened.
Reporter | ||
Comment 2•9 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #1)
> We could have an option in the user management pages, where the user can
> request a submitter value, with a justification. An admin evaluates it and
> assigns the submitter value if everything's okay, and then the developer can
> use it. If a developer submits a version with an unassigned or incorrect
> submitter, it's auto-rejected with an explanation of how to request it. This
> way we separate it from the review process, which is already overburdened.
Sounds like a plan, I really like it. Should we spin off your description as an AMO bug and leave this one in place for the add-ons manager / UX side?
Comment 3•9 years ago
|
||
I'd like to hear from Mossop and Andy first, since it's a non trivial effort that will only benefit a small group of developers who need this sort of extra verification.
Flags: needinfo?(dtownsend)
Flags: needinfo?(amckay)
Comment 4•9 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #3)
> I'd like to hear from Mossop and Andy first, since it's a non trivial effort
> that will only benefit a small group of developers who need this sort of
> extra verification.
I agree that it might be useful, but like with other installation changes I don't rate it as high priority.
Flags: needinfo?(amckay)
Comment 5•9 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #3)
> I'd like to hear from Mossop and Andy first, since it's a non trivial effort
> that will only benefit a small group of developers who need this sort of
> extra verification.
The work to display such a field from install.rdf in the install UI is pretty straightforward, the work here would be all on AMO to ensure that is correct and meaningful to users. If I create an AMO account named "Norton Utilities" for example are you going to do the time and work to verify that I am Norton? If not this is an avenue to spoof the user into trusting an extension more than they should. The bar here should probably be pretty high. We don't generally display the owner of SSL certificates unless they are EV in Firefox for example because we know that CAs don't do enough verification for DV certificates for the information to be beneficial to users.
Flags: needinfo?(dtownsend)
Comment 6•9 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #5)
> The bar here should probably be pretty high.
I agree. Not only should we need to actually verify the user's identity, but it should only be done for cases where it's really needed (security-related add-ons, major software firms).
(In reply to Giorgio Maone from comment #2)
> Sounds like a plan, I really like it. Should we spin off your description as
> an AMO bug and leave this one in place for the add-ons manager / UX side?
Yes. Please please file the AMO bits on Github: https://github.com/mozilla/olympia
Reporter | ||
Comment 7•9 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #6)
> Please please file the AMO bits on Github:
> https://github.com/mozilla/olympia
https://github.com/mozilla/olympia/issues/1177
Updated•9 years ago
|
Severity: normal → minor
Priority: -- → P4
Updated•9 years ago
|
Whiteboard: triaged
Comment 8•7 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
Updated•7 years ago
|
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Comment 9•5 years ago
|
||
We have no plans for doing this in the foreseeable future. Other forms of confirmation exist or are being worked on, and we haven't heard any user feedback on this particular issue.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.