consider force signing add-ons requirements on in beta/release for thunderbird (too)

NEW
Unassigned

Status

Thunderbird
General
3 years ago
3 years ago

People

(Reporter: Magnus Melin, Unassigned)

Tracking

Trunk
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

3 years ago
+++ This bug was initially created as a clone of Bug #1163046 +++

So firefox is forcing add-ons to be signed for official releases and betas, since bug 1163046.

I realize signing is a bit of a hazzle for add-on developers, but I'd still follow the policy that firefox uses. Doing stuff differently doesn't play well in the long run: features and tests are prone to break, like they did for bug 1167986.

Also, since it's used in firefox you already know what to do if you're creating add-ons for multiple apps.

Comment 1

3 years ago
Thanks for opening this, Magnus.

I would argue against this because it creates a lot of hastle for our addon developers, but unlike with Firefox, we do not have a history of rogue addons that needs a fix. So we are creating problems for our addon developers with no perceived benefit. We will lose addons over this, or people will just stop updating Thunderbird.

There are lots of add-on authors who have gotten frustrated in trying to deal with the official addon channels at Mozilla, and decided to self-host their addons instead. Or their are one-off addons that currently work, and now will break. "It might break someday" is not a sufficiently strong argument to justify this hastle.
A couple of things to note:

* Since bug 1164168 add-on signing detection has been turned off in Thunderbird

* AMO aren't currently planning on signing add-ons that are compatible with Thunderbird but not Desktop

* All of our comms so far have been saying that other applications won't be requiring signing.

* You may need to implement some of the new UI pieces that we have for Firefox, I can't remember what methods for add-on install Thunderbird supports currently.

* You will need a new hotfix signing certificate

Comment 3

3 years ago
I agree with comment #1, there is more hassle involved with such a step than really preventing anything. First of all, there are various popular extensions for Thunderbird out there which are /not/ hosted on AMO but only available from the author's own website or a well-established mirror, which would be rendered useless if signing became mandatory. Furthermore, it's much more difficult to install an add-on "by accident" in Thunderbird than in Firefox, given that one can't just go to a web page and install the XPI file directly from there. In contrast, you'll have to explicitly download the XPI file with a browser and install it manually (if not on AMO). That's a frequently encountered support issue in the MZ forums.

My vote for a WONTFIX of this bug.

Comment 4

3 years ago
To add another thought: Enforcing signed add-ons in retail Thunderbird would require to also build unbranded versions to allow institutions/organizations to deploy their custom add-ons; thus, effectively reintroducing explicit ESR builds for Thunderbird which were abandoned when TB retail switched to build from ESR entirely.
(Reporter)

Comment 5

3 years ago
I read up on this some more. https://wiki.mozilla.org/Addons/Extension_Signing is the official page.

So it's really not any change for add-ons served from AMO. those will get signed automatically. If you don't use AMO it's more work yes, but:
 * there may be (bad) reasons why add-ons aren't on AMO in the first place
 * Thunderbird can install add-ons from the add-ons manager, a web page, or from a file. Since you can't really open web pages easily, it's the add-on manager or from a file. The UX for that not good though, so giving a good incentive to have your extension hosted at AMO would be a great UX win actually! Like comment 3 says, many users can't figure out how to install from file.

That we haven't heard much about malicious add-ons in thunderbird doesn't mean they don't exist. We're just not as attractive as firefox due to less users. But, when firefox requires signing our relative attractiveness may increase. (3rd party side-loading of bad extensions should also get much harder.) 

When people ask why we don't require signing we need to have a better reason than "add-on devs couldn't be bothered". And, when we do get some publicized problem with unsigned add-ons it could easily get us a lot of bad publicity.

As I see it the only slight problem is we don't have a developer edition, but I'd expect that's something we can be worked out somehow. If not, I don't think having devs use aurora/nightly for testing is that unreasonable.
(In reply to Dave Townsend [:mossop] from comment #2)
> * All of our comms so far have been saying that other applications won't be
> requiring signing.

I think this is the most important and strong argument against it. As you can see in m.a.user-experience, there has been quite a commotion about this topic, and the question about Thunderbird and Seamonkey has been brought up more than once. All communication was that this won't be a topic for Thunderbird at the moment, and I think it would be very bad timing to change our stance.

Personally I think we should wait and see how it goes for Firefox. Some mentioned that if it turns out that this does not notably avoid malware for Firefox, this feature may be rolled back. If we turn it on now, we'll create some unnecessary aggravation for a feature that might be turned off again.

Also, as Thunderbird is often used in enterprise environments, this might bring up the same discussion again about how some folks don't want to send their company-internal addons through Mozilla's signing service.

Comment 7

3 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #6)
> Also, as Thunderbird is often used in enterprise environments, this might
> bring up the same discussion again about how some folks don't want to send
> their company-internal addons through Mozilla's signing service.

Make that "some folks /can't/ send their company-internal addons" possibly for legal reasons like interlectual property, etc.

Also, you (Magnus) didn't address the need for unbranded builds not having that restriction (which Firefox will have even for the release channel, as I understand it).
(Reporter)

Comment 8

3 years ago
Re private add-ons used in enterprise environments the wiki page says: We haven't announced our plan for this case yet. Stay tuned. In the interim, ESR will not support signing at least until version 45, which won't come out until 2016. 

I doubt that there somehow would exist more company internal add-ons for thunderbird than firefox.

I haven't read the communication, but since there's been no real discussion about whether Thunderbird would use it or not, of course an easy answer is "not a topic for thunderbird". It's *now* up to us to decide. That's not changing a stance, that's taking a stance in the first place.

Re unbranded builds, I would assume that's fairly easily doable if we want to.

Comment 9

3 years ago
(In reply to Magnus Melin from comment #8)
> ESR will not support signing at least until version 45, which won't come out until 2016. 

So does Thunderbird, thus ...

> It's *now* up to us to decide.

why trying to force this decision at this time if it's still almost a year away, with TB 38.0 not even released yet, rather than just leaning back for now and watch how Firefox gets pounded once the signing requirement hits the releases?

The rationale for enterprise builds should be obvious: Leave the IT people in charge, they usually know what they are doing.
(Reporter)

Comment 10

3 years ago
If someone didn't realize, yes, for thunderbird this is only relevant for the thunderbird 45 (and betas until then). If firefox drops the signing requirement we probably should too, but the likelihood of that would appear to be very very small.

However, postponing the decision would be hurtful as tests will break (already broke), likely code changes need to be ported over, we should make sure amo auto-signs thunderbird add-ons etc. Also it gives add-on authors more time to prepare.
Another con-point for signing: AMO does not allow betas that have warnings with any level of "signing severity". One warning that causes signing severity medium is binary components. As a result, if we enable signing for Thunderbird then we can't do any more betas of Lightning on addons.mozilla.org until we get rid of the binary component.

Comment 12

3 years ago
Magnus, so far you are the only one arguing in favor of signing. It would be an enormous amount of work for Thunderbird devs, AMO folks (your comment 5 "it's really not any change for add-ons served from AMO" is not true until the AMO folks do a lot of background work to enable signing), and addon-devs.

At this point, we previously decided to NOT sign addons, and we need to get bugs fixed like bug 1167986 to fix broken tests. Even if we implemented signing, it would be months away. It is unacceptable to have broken tests for such a long time.

So as far as I am concerned, though we can keep this bug open for discussion, the current status quo is that we are NOT going to require test signing, and we should proceed on that assumption with other needed code fixes.

Comment 13

3 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #11)
> Another con-point for signing: AMO does not allow betas that have warnings
> with any level of "signing severity". One warning that causes signing
> severity medium is binary components. As a result, if we enable signing for
> Thunderbird then we can't do any more betas of Lightning on
> addons.mozilla.org until we get rid of the binary component.

Fixed.
(Reporter)

Updated

3 years ago
Blocks: 1210995
(Reporter)

Updated

3 years ago
Blocks: 1199907
(Reporter)

Updated

3 years ago
Blocks: 1204945
You need to log in before you can comment on or make changes to this bug.