1206696 - Adding Firefox as a supported appversion does not sign previously unsigned add-ons

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

STR:

1) Upload an (unlisted?) add-on supporting Seamonkey
2) Get the addon fully reviewed
3) Add Firefox to supported applications on the version page (e.g. 24.0 - 44.0)


Result:
* The add-on remains unsigned

Expected:
* The add-on should be signed, if signing validation checks have passed.

This happened with an unlisted add-on recently, if you need to know which one please ping me.

Comment 1

[Mathieu Agopian [:magopian]]

This poses another question: should we simply sign every add-on (extension) that supports firefox? Or even every add-on that is signable (every xpi, but multi-packages)?

We only wanted to sign add-ons that were supporting Firefox, and only if they were supporting versions recent enough (if they were default to compatible, at least firefox 4, if they weren't, at least firefox 37). But I believe this was only to not have to sign all the add-ons when running the bulk signing script.

We could maybe just sign each and every add-on when they're submitted now?

For some context, we're also planning on signing Firefox for Android add-ons (see bug 1185789)

What do you think :dveditz :mossop?

Comment 2

[Daniel Veditz [:dveditz]]

This is a better question for Jorge and Kris since it's more about AMO policy than client. Is there a different level or focus of review for a SeaMonkey app vs. a Firefox app (or Thunderbird or Fennec)? My main concern would be whether this would enable a way to get around review requirements.

One way or another we need to resolve this though. It's unusual for an add-on to start as SM/TB and then add Firefox rather than the reverse, but expanding compatibility of add-ons definitely happens. Doesn't matter to me if you just start off signing everything at review time regardless of the target application, or if you kick off signing when the target applications are changed to include Firefox (or Firefox for Android in the future). --ASSUMING--, that is, that the review scope is the same.

[Why would someone even submit an unlisted SeaMonkey add-on? If we're not signing them and not hosting them isn't that wasted effort?]

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

It seems to me that this is an extremely unlikely scenario, so it's reasonable to request the developer to take an additional step (submit a new version). Add-ons that aren't compatible with Firefox or Firefox for Android should in theory be reviewed with the same level of scrutiny, but it's likely they aren't. And, like Dan points out, if someone is submitting an unlisted add-on that doesn't support Firefox then they probably don't understand the limits of the signing restrictions. Maybe we should have some notification during submission about this, since it sounds like we're currently accepting all add-ons as unlisted.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I agree this is an edge case and it is reasonable to ask the developer to submit a new add-on version. We could well change this into an enhancement bug to add some sort of notification as you described.

Comment 5

[Mathieu Agopian [:magopian]]

Ok, closing this as WONTFIX then, thanks.