Bug 1292780 - mozilla-adblockplus disabled by default in Firefox 43
Summary: mozilla-adblockplus disabled by default in Firefox 43
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mozilla-adblockplus
Version: 23
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Andreas Thienemann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-18 10:31 UTC by Andre Robatino
Modified: 2016-03-25 05:00 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-25 05:00:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Andre Robatino 2015-12-18 10:31:26 UTC
Description of problem:
Firefox 43 disables unsigned extensions by default. Must go to about:config and toggle xpinstall.signatures.required to false to enable mozilla-adblockplus.

Version-Release number of selected component (if applicable):
mozilla-adblockplus-2.6.11-1.fc23.noarch
firefox-43.0-1.fc23.x86_64

How reproducible:
always

Comment 1 Andre Robatino 2015-12-19 08:30:17 UTC
The xpinstall.signatures.required option is expected to not exist anymore in Firefox 44, scheduled for January 26 release, so this needs to be fixed by then.

Comment 2 Kevin Kofler 2015-12-20 01:47:53 UTC
This needs to be fixed in our Firefox packaging. This iOS-like DRM scheme is entirely incompatible with Free Software and unacceptable for Fedora. If Mozilla refuses to allow us to disable it, we need to go the Iceweasel route.

I am putting this to FESCo's attention.

Comment 3 Kevin Kofler 2015-12-20 02:03:02 UTC
https://fedorahosted.org/fesco/ticket/1518

Note that this CANNOT be fixed in this addon package without violating the Fedora policy that bans shipping binary blobs, and that the blobs are also not going to work on secondary architectures.

Comment 4 Russell Golden 2016-01-01 18:09:47 UTC
... wow.

I package the HTTPS Everywhere plugin with the signature, but that's because I haven't gotten around to modifying the packaging process from "extracting the XPI" to "actually building the thing."

In the meantime, should we just grab the signature for each package and add it?

Comment 5 Kevin Kofler 2016-01-09 06:15:28 UTC
Adding the signature doesn't help if there is compiled code (that obviously needs to be built from source), if we are unbundling things such as jQuery, or if we are doing any other modification to the shipped files.

Comment 6 Russell Golden 2016-01-18 22:53:55 UTC
There aren't any binaries, not even sqlite. the .jar file that used to be there is gone, too. (why it was a .jar, i have no idea, because it never had java, it was just a .zip file with a weird extension)

We aren't unbundling anything. Just grabbing the source, building it, and...

... modifying the install.rdf (at the developer's suggestion) to prevent the extension from updating itself into the user's profile directory.

Crap.

Well. As a workaround, we can remove that patch. It's the only modification we make. We'd have to grab the signatures and add them in after the build.

Comment 7 Russell Golden 2016-01-18 22:56:35 UTC
All the code is in javascript, if that wasn't clear. there are no actual compiled code binaries. if it isn't some form of human-readable text in the resulting package, it's an image.

Comment 8 Andre Robatino 2016-03-25 05:00:59 UTC
With firefox-45.0.1-2.fc23, the extension is enabled by default (even with xpinstall.signatures.required set to the default true).


Note You need to log in before you can comment on or make changes to this bug.