Bug 1292780

Summary: mozilla-adblockplus disabled by default in Firefox 43
Product: [Fedora] Fedora Reporter: Andre Robatino <robatino>
Component: mozilla-adblockplusAssignee: Andreas Thienemann <andreas>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: andreas, Bert.Deknuydt, chkr, diego.ml, dominik, goeran, lantw44, mtasaka, niveusluna, reklov, ts, watanabe.yu
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-25 05:00:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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).