MozillaZine

Mandatory signing requirement for add-ons is coming

Talk about add-ons and extension development.
Lemon Juice
 
Posts: 781
Joined: June 1st, 2006, 9:41 am

Post Posted January 20th, 2015, 7:04 am

I've noticed a sentence that worries me a bit in the latest SM status meeting:

AMO and addon-signing. All addons will have to be signed and reviewed by AMO editors including extensions not hosted on AMO. Otherwise they'll be disabled.

I haven't found any more information on this - what does this mean and how is this going to be implemented? Is Mozilla going the same route as Chrome with imposing their rules on what extensions can be installed and denying users the right to choose on their own? :evil: Depending on how this gets implemented it can mean the end of the add-on converter as well as any other independent modified extensions sites.
Last edited by rsx11m on May 27th, 2015, 2:36 pm, edited 2 times in total.
Reason: changed title from "may be" to "is" given that it seems to be happening for sure
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

therube

User avatar
 
Posts: 19109
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted January 20th, 2015, 7:51 am

Last edited by therube on January 20th, 2015, 7:56 am, edited 1 time in total.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

WaltS48

User avatar
 
Posts: 3741
Joined: May 7th, 2010, 9:38 am
Location: Pennsylvania, USA

Post Posted January 20th, 2015, 7:55 am

AMO and addon-signing. All addons will have to be signed, uploaded to AMO then reviewed by AMO editors including extensions not hosted on AMO. Otherwise they'll be disabled. Discussion in mozilla.addons.user-experience


Discussion: https://groups.google.com/d/msg/mozilla ... D2p_CFAEUJ
Linux Desktop - AMD Athlon(tm) II X3 455 3.3GHz | 8.0GB RAM | GeForce GT 630
Windows Notebook - AMD A8 7410 2.2GHz | 6.0GB RAM | AMD Radeon R5

therube

User avatar
 
Posts: 19109
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted January 20th, 2015, 8:02 am

And more generally, mozilla.addons.user-experience

("Experience". When you hear a word such as that, in that kind of context, you know were about to be shoveled a lot of bull.)
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

Lemon Juice
 
Posts: 781
Joined: June 1st, 2006, 9:41 am

Post Posted January 20th, 2015, 8:31 am

I was so happy last year to know that Mozilla stayed sane in allowing add-ons from all sources unlike Chrome and now they are handicapping the browser in the same way in the name of security. No user choice.

Things seem to be decided upon now so the only thing left for us is hope that SeaMonkey will not require all this signing cr**, especially since SM users are usually more tech-savvy than Fx users and are used to configuring their software.

I just can't help but notice that all browsers are trying to become the same - why can't we have differentiation so everyone can choose what suits them best?...
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted January 20th, 2015, 8:44 am

Lemon Juice wrote:Things seem to be decided upon now so the only thing left for us is hope that SeaMonkey will not require all this signing cr**, especially since SM users are usually more tech-savvy than Fx users and are used to configuring their software.

Since add-on management is Toolkit code, I'm not very optimistic that this will happen (the hope is that there is some build-time switch that applications can use to disable that "feature"). Anyway, it was mentioned in today's SeaMonkey Status Meeting, so the problem is known at least on that side and will (hopefully) lead to some action to minimize the impact for the other Gecko applications.

Frank Lion

User avatar
 
Posts: 20063
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom

Post Posted January 20th, 2015, 8:46 am

Lemon Juice wrote:I just can't help but notice that all browsers are trying to become the same - why can't we have differentiation so everyone can choose what suits them best?...

These days, no commercial company is set up with the intention of providing more edge user choice. They all go for the same main user market, which is where the money is.

That's why all modern cars look the same.
Metal Lion latest SeaMonkey & Thunderbird Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)

Lemon Juice
 
Posts: 781
Joined: June 1st, 2006, 9:41 am

Post Posted January 20th, 2015, 9:08 am

rsx11m wrote:Since add-on management is Toolkit code, I'm not very optimistic that this will happen (the hope is that there is some build-time switch that applications can use to disable that "feature"). Anyway, it was mentioned in today's SeaMonkey Status Meeting, so the problem is known at least on that side and will (hopefully) lead to some action to minimize the impact for the other Gecko applications.

The main discussion mentions providing debug builds of Beta and Release versions of Firefox that will allow unsigned add-ons so maybe this mechanism could be used to build SM - just without calling it "debug"?

Maybe for the general Fx audience this change will not be harmful but we SM users must often rely on modified extensions because the official choice is so much smaller than for Fx.

Frank Lion wrote:These days, no commercial company is set up with the intention of providing more edge user choice. They all go for the same main user market, which is where the money is.

That's why all modern cars look the same.

Yeah, maybe the problem is Mozilla has become too big and too commercial. Now they must try as hard as possible to keep the large main user market in order not to lose the funding coming from Yahoo.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

barbaz
 
Posts: 1680
Joined: October 1st, 2014, 3:25 pm

Post Posted January 20th, 2015, 11:17 am

rsx11m wrote:
Lemon Juice wrote:Things seem to be decided upon now so the only thing left for us is hope that SeaMonkey will not require all this signing cr**, especially since SM users are usually more tech-savvy than Fx users and are used to configuring their software.

Since add-on management is Toolkit code, I'm not very optimistic that this will happen (the hope is that there is some build-time switch that applications can use to disable that "feature").

Wow, I really hope that doesn't get pushed to SeaMonkey and forcibly kill those of my self made SeaMonkey add-ons which, due to e.g. licensing issues, I *can't* upload to AMO (or anywhere else, for that matter) even if I wanted to. :evil:

If it's not going to be possible to just not have this power-user-antagonistic "feature" in SeaMonkey:
Are they at least going to offer extension devs and power users a way to, say, self-sign add-ons (*completely* offline / locally) and then add ourselves as a trusted signer alongside Mozilla so we can at least keep developing our own add-ons for personal use? If so, would there be a way to leverage such a thing for the converter, even though it would require the end user to add Lemon Juice as a trusted signer?
I would think such a thing could have similar mechanism as current certificate management without making it less able to do what it's intended to do, no?
*Always* check the changelogs BEFORE updating that important software!

Frank Lion

User avatar
 
Posts: 20063
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom

Post Posted January 20th, 2015, 11:53 am

barbaz wrote:Are they at least going to offer extension devs and power users a way to, say, self-sign add-ons

Mozilla can self-sign my backside.

Back in 2004, there was this feeble browser than looked grim, couldn't do much and had no user support for it at all. The Oprah browser had the same marketshare at the time.

The community, in the form of these very forums, MozillaZine, provided the sole English user support for it for around 5 years and the wider community provided better functionality and appearance for it in the form of extensions and themes. It was the same Mozilla who were asking/begging us to do this.

I think you all get the general drift here?.... :)
Metal Lion latest SeaMonkey & Thunderbird Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted January 20th, 2015, 1:44 pm

From https://docs.google.com/document/d/1Khp ... mWmEmOses/
Developer Mode

Requiring developers to sign their add-on during development would be cumbersome and kill productivity so we must support a “Developer Mode” that disables signature verification. A global on/off toggle would leave developers unprotected so we will instead support developers whitelisting the ID of the add-on(s) for which they would like to disable signature verification.

We know malware would be quick to abuse such a configuration setting so it can only be supported in developer builds: Nightly, Aurora, debug builds on any branch, and as an autoconfig option for self-built binaries. Official Beta and Release versions would not support whitelisting.

If it's a build-time autoconfig option, SeaMonkey would hopefully be able to be built with the whitelisting option in its releases. This might still imply that whoever wants to run the add-on has to extract its ID and add it to the whitelist, that's a tough obligation for the average user... :doubt:

But then, it still looks like a draft at this moment, thus specs may change.

Lemon Juice
 
Posts: 781
Joined: June 1st, 2006, 9:41 am

Post Posted January 20th, 2015, 1:57 pm

barbaz wrote:Are they at least going to offer extension devs and power users a way to, say, self-sign add-ons (*completely* offline / locally) and then add ourselves as a trusted signer alongside Mozilla so we can at least keep developing our own add-ons for personal use? If so, would there be a way to leverage such a thing for the converter, even though it would require the end user to add Lemon Juice as a trusted signer?
I would think such a thing could have similar mechanism as current certificate management without making it less able to do what it's intended to do, no?

It's to early to tell what will be possible because the SM developers are only beginning to discuss it. I only wonder if the overwhelming (!) majority of them are also in favour of getting rid of this new "feature"? And also - are there any SM users who appreciate this new Mozilla "security" feature and would be happy to see it in SM? They should reveal themselves :!: :-"

Frank Lion wrote:Mozilla can self-sign my backside.

Very well said. It's hard for me to image how anyone among the Fx developers could even begin to *think* about the possibility of crippling the browser in such a way destroying one of its most powerful and useful attributes. Yes, the drift is clear.

If SM doesn't implement the changes then it will become THE powerful browser of the Mozilla family - just by comparison. And also, well, Pale Moon, which I suspect will also remain traditional in not requiring any add-on signing.

rsx11m wrote:If it's a build-time autoconfig option, SeaMonkey would hopefully be able to be built with the whitelisting option in its releases. This might still imply that whoever wants to run the add-on has to extract its ID and add it to the whitelist, that's a tough obligation for the average user... :doubt:

But then, it still looks like a draft at this moment, thus specs may change.

Thanks for the info. Yes, things may change but it looks like some kind of solution can be worked out. Or maybe it would be possible to simply implement (by SM devs) right into the toolkit a simple switch and an if-statement that allows the signing check to be disabled completely - Fx devs wouldn't have to use it at all so perhaps they wouldn't mind if it existed for other applications?
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted January 20th, 2015, 3:15 pm

Lemon Juice wrote:Or maybe it would be possible to simply implement (by SM devs) right into the toolkit a simple switch and an if-statement that allows the signing check to be disabled completely - Fx devs wouldn't have to use it at all so perhaps they wouldn't mind if it existed for other applications?

It is certainly possible (to some extent) for an application to maintain its own fork of specific files, and SeaMonkey does though in a couple of instances. However, it always means maintaining yet another piece of code and making sure that any fixes applied to the main code are merged into your own fork without breaking anything (which for a complex component like the Add-ons Manager can be quite a bit of work).

Ideally, there is a 3-state build-time configuration option (fully enable signing control; enable signing control but also enable whitelisting; fully disable signing control) but we may have to wait until respective pieces of code are coming up or at least those options can be discussed in a bug report.

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted January 20th, 2015, 3:24 pm

I've split this discussion off viewtopic.php?f=40&t=2834855&start=195 as it warrants some better visibility and is also better suited for the SM Builds forum than SM Support.

Lemon Juice
 
Posts: 781
Joined: June 1st, 2006, 9:41 am

Post Posted January 20th, 2015, 4:08 pm

rsx11m wrote:
Lemon Juice wrote:Or maybe it would be possible to simply implement (by SM devs) right into the toolkit a simple switch and an if-statement that allows the signing check to be disabled completely - Fx devs wouldn't have to use it at all so perhaps they wouldn't mind if it existed for other applications?

It is certainly possible (to some extent) for an application to maintain its own fork of specific files, and SeaMonkey does though in a couple of instances. However, it always means maintaining yet another piece of code and making sure that any fixes applied to the main code are merged into your own fork without breaking anything (which for a complex component like the Add-ons Manager can be quite a bit of work).

I didn't mean maintaining a fork of toolkit files but simply applying the applicable switch to the common toolkit code that is used by Fx and SM. I meant Fx devs hopefully wouldn't mind it because they simply wouldn't use it.

But yes, let's wait because as you say the applicable switches may be already available.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 2 guests