MozillaZine

Mandatory signing requirement for add-ons is coming

Talk about add-ons and extension development.
rsx11m
Moderator
 
Posts: 14429
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted February 16th, 2015, 8:24 am

lithopsian wrote:Although the documentation states that developers will have to use special Firefox versions for testing not-yet-signed addons, a preference is planned to allow installation of unsigned addons (not implemented yet though):
https://bugzilla.mozilla.org/show_bug.cgi?id=1038068

That bug refers to an old Bug 238960, Require XPIs to be signed, which was opened in 2004 and initially won't-fixed for similar concerns as voiced here, then reopened for further discussion. A lot of the points raised there are still valid a decade later, thus an interesting read.

lithopsian
 
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Post Posted February 16th, 2015, 9:22 am

rsx11m wrote:
lithopsian wrote:Although the documentation states that developers will have to use special Firefox versions for testing not-yet-signed addons, a preference is planned to allow installation of unsigned addons (not implemented yet though):
https://bugzilla.mozilla.org/show_bug.cgi?id=1038068

That bug refers to an old Bug 238960, Require XPIs to be signed, which was opened in 2004 and initially won't-fixed for similar concerns as voiced here, then reopened for further discussion. A lot of the points raised there are still valid a decade later, thus an interesting read.

It is still listed as blocking the current addon signing revamp tracking bug.

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

Post Posted February 16th, 2015, 2:49 pm

"blocking" in this sense simply means that it's tracked by the meta bug, nothing more and nothing less.

lithopsian
 
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Post Posted February 16th, 2015, 3:02 pm

rsx11m wrote:"blocking" in this sense simply means that it's tracked by the meta bug, nothing more and nothing less.

I know you like to disagree with everything I say, but this bug was only raised six months ago. It was also recently added as a blocker to another signing-related (non-meta) bug. So we can only hope they might actually do it. If they had already decided not to do it then it would be very simple to close the bug. There is a comment that it should be compiled out of Firefox release versions though.

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted February 16th, 2015, 3:21 pm

They have explicitly mentioned that there will not be a preference.... for obvious reasons: a preference would make the whole system pointless as any drive-by installer would just disable the signing requirement. Remember that not every bug created or added to a new feature blocklist is something that is planned. That *was* six months ago and it's likely that they've wised up. For instance, since that time they've changed the searchbar so that you cannot remotely change the search engine via editing prefs.js (which also breaks the ability for companies to do that through deployment).
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted February 16th, 2015, 4:10 pm

mcdavis wrote:On m.addons.user-experience, Dan Veditz said:

> Then use a popup like Chrome does (that can't be bypassed). It would be much less annoying than this.

For an add-on that requires a Firefox restart to install there's nothing we can do that can't be bypassed. Chrome benefits from never having allowed extensions to be as invasive/integrated as Mozilla's.


What's he referring to?


If the verification process happens in JS then an XUL extension could wipe it out. Seems like it would have to happen in the Core somewhere to actually work. Let's hope this doesn't become a rallying cry for the dismantling of XUL extensions.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted February 16th, 2015, 4:23 pm

patrickjdempsey wrote:If the verification process happens in JS then an XUL extension could wipe it out. Seems like it would have to happen in the Core somewhere to actually work. Let's hope this doesn't become a rallying cry for the dismantling of XUL extensions.


I consider XUL gone (eventually, unless something's changed in what the developers are saying about that?) and that everything I write in XUL will later have to be rewritten in HTML. So it goes. My concern, which is probably the same as your concern, and maybe what you were really getting to, is about what we can do with add-ons, and whether there's a vector that's specific to the kind of add-ons we write (having to do with restarting), which would relate to that concern.
Last edited by mcdavis on February 16th, 2015, 4:34 pm, edited 1 time in total.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted February 16th, 2015, 4:33 pm

patrickjdempsey wrote:They have explicitly mentioned that there will not be a preference....


Reading through the bug, I think the existence of a pref as talked about there is the same as what we already understand:

1 - For official Release and Beta, the pref will not exist in built Firefox. Add-ons must be signed to install (or continue running if previously installed with older Firefox). The pref exists in source code only, but is removed as part of building for Release and Beta.
2 - For Aurora and Nightly, the pref will exist but be disabled by default. Desirous users can flip the pref to allow installing unsigned add-ons, which would still be prevented without flipping the pref. The pref is defined at build-time with a special setting (maybe some acsomething flag).
3 - For unofficial Release and Beta allowing unsigned add-ons, I can't tell if the pref is involved.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

lithopsian
 
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Post Posted February 16th, 2015, 4:33 pm

I give up. You are either not reading what I (or the bugzilla authors) write, or wilfully ignoring it for your own obscure reasons. See ya'll later when the dust settles.

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted February 16th, 2015, 5:53 pm

From one of the dozens of conversations over at User Experience:

https://groups.google.com/forum/#!topic ... Tb9ndgzBkg

Jorge wrote:The unbranded and dev versions will have the signing enforcement off by
default, but they will have a setting to turn it on. This setting won't
exist on Beta and Release versions.


So no pref in branded Release/Beta. Pref in unbranded Release/Beta and all Nighty/Dev builds. The pref is default to off, but can be enabled to allow authors to test to see if the signing is working.

mcdavis wrote:My concern, which is probably the same as your concern, and maybe what you were really getting to, is about what we can do with add-ons, and whether there's a vector that's specific to the kind of add-ons we write (having to do with restarting), which would relate to that concern.


I don't think there's anything in there *we* have to worry about. As registered AMO developers, our existing extensions should automatically get signed and that's that. I am more worried about this move being used as a tactic to completely kill XUL extensions, although I'm not sure how SeaMonkey would deal with such a move.

There are some grey areas though:

1. It's not entirely clear to me if *experimental* extensions are automatically signed or if they will require a secondary code review. That could create a real bog-down in a process

2. Will AMO be able to handle all of this extra traffic in a meaningful time frame? Extensions reviews for Firefox, even for experimental addons was atrociously slow last time I tried to get anything through. And a three-week or more wait just to get something to a stage where a tester can look at it seems like a non-starter.

3. It's not entirely clear if signatures are version independent. Will every single update have to be signed separately?

4. If the Extensions Updates mechanism is used for downloading the "certs" what happens to users who have automatic updates disabled? And even if the check is mandatory... what happens if the AMO servers are down, as they tend to be right around update time? Or if there's a bad connection?

5. Is there any protection planned against malware authors just mimicking an existing, signed extension? Checksum hash? If so, that gets really weird with platform-specific versions, which would all have different checksums.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted February 16th, 2015, 6:45 pm

patrickjdempsey wrote:From one of the dozens of conversations over at User Experience:

https://groups.google.com/forum/#!topic ... Tb9ndgzBkg

Jorge wrote:The unbranded and dev versions will have the signing enforcement off by
default, but they will have a setting to turn it on. This setting won't
exist on Beta and Release versions.




True, that is more recent than the referenced bug.

patrickjdempsey wrote:I am more worried about this move being used as a tactic to completely kill XUL extensions


I thought that was already a given, as part of the long-term plan. Am I wrong?
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

LoudNoise
New Member

User avatar
 
Posts: 40048
Joined: October 18th, 2007, 1:45 pm
Location: Next door to the west

Post Posted February 16th, 2015, 6:51 pm

patrickjdempsey wrote:
4. If the Extensions Updates mechanism is used for downloading the "certs" what happens to users who have automatic updates disabled? And even if the check is mandatory... what happens if the AMO servers are down, as they tend to be right around update time? Or if there's a bad connection?


Or if your AV has a security helper such as local proxy.
Post wrangler
"Choose between the Food Select Feature or other Functions. If no food or function is chosen, Toast is the default."

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted February 16th, 2015, 6:52 pm

I've asked several times and the folks I talked to claimed that Gecko and XUL weren't going away, but I do agree that it's probably eventual. Especially if Mozilla keeps ticking off their users until the user base is so small that they no longer have the income to support the 20 different projects they want to build.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted February 16th, 2015, 6:54 pm

LoudNoise wrote:
patrickjdempsey wrote:
4. If the Extensions Updates mechanism is used for downloading the "certs" what happens to users who have automatic updates disabled? And even if the check is mandatory... what happens if the AMO servers are down, as they tend to be right around update time? Or if there's a bad connection?


Or if your AV has a security helper such as local proxy.


Or in being super clever you've blocked addons.mozilla.org with a HOSTS file to prevent automatic updates of your broken old extensions? I really wouldn't be surprised if there are some geniuses out there doing this right now.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

mcdavis

User avatar
 
Posts: 3195
Joined: December 9th, 2005, 5:51 am

Post Posted February 16th, 2015, 9:19 pm

Some more about the existence of a controlling pref for requiring add-on signing, in Aurora and Nightly, from the topic "Add-on signing.. can I turn it on manually in nightly?"

At 2/11/2015 5:37 PM, Bryan said:

Will it be possible to force add-on signing enforcement on in nightly? I'd much prefer to have that extra security.

At 2/12/2015 12:47 PM, Mike Connor said:

The intent was that this feature will default on across all channels, with
a pref available to disable it. I think that's still the plan. Dan, can
you confirm?

At 2/12/2015 3:47 PM, Dan Veditz said:

Yes. All channels, even "dev" channels will default to enforcing signed
add-ons, the difference will be "dev" channels will support a pref to
disable the enforcement. Users will still be informed whether the add-on
was unsigned or not though.

-----------------

So there was conflicting information (Jorge: default off; Dan Veditz: default on) given in what was said about a pref in Aurora and Nightly.
Theme Development is Radical Participation.
NNL Beta Builds for Current and Up-coming Firefox
Dear User: Your Help is Needed

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 2 guests