= phenomenon = With the release of Firefox 43, Firefox has started refusing by default to load any extensions that are not signed. With the next release, Firefox 44, upstream is even removing the option to load unsigned extensions entirely. This effectively amounts to an iOS-style DRM scheme, disallowing to install any extensions not coming from Mozilla. As a results, this prevents the user from exercising the fundamental 4 freedoms of Free Software when it comes to Firefox extensions. (It also has the side effect of breaking all Firefox extensions packaged in Fedora, in a way that cannot be fixed without shipping binary blobs, in violation of our policy to build everything from source.) Such a DRM scheme should NOT be allowed in Fedora.
= reason = We go through great lengths to allow the user to use modified software at his/her own discretion. Even our own package signature mechanism can be disabled by a gpgcheck=0 setting, or even by just using RPM directly (which does not check signatures by default). We should not allow programs packaged in Fedora to enforce such a signature mechanism on their own with no opt out.
= recommendation = There needs to be a Fedora-wide policy banning DRM schemes of this kind with no opt out. (I would also recommend disabling enforcement by default where it exists, but that might be more controversial.)
As an immediate action, any update to Firefox 44 must be blocked by FESCo unless the option to disable checking the signatures is reinstated. If that is not possible within the Firefox trademark policies, the only option is to finally rebrand Firefox.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1292780
https://bugzilla.redhat.com/show_bug.cgi?id=1292782
(but any third-party extensions, or extensions the user locally modified and rebuilt, e.g. to fix a bug, are affected exactly the same way).
See also https://wiki.mozilla.org/Addons/Extension_Signing for upstream's description of this misfeature.
Oh, and our RPM signature verification scheme also allows users to easily import third-party repository public keys. The Mozilla scheme does not allow that either!
I was bitten by this as well (as the maintainer of mozilla-noscript and user of Fedora-packaged Firefox addons). I could work around this in mozilla-noscript because it doesn't contain any binary blobs, but all other packaged extensions were disabled by the firefox 43 update.
Another option would be to somehow automate the signing of our modified packaged addons by Mozilla signing service. There seems to be an API for this: http://olympia.readthedocs.org/en/latest/topics/api/signing.html , but the process would have to look like this, I guess:
This is very cumbersome, IMHO.
+1 to iceweasel
I'll start by stating that I agree 95% with the top-level premise. I don't think that Fedora should ever ship a package that requires DRM that is not in the user's control. Which is to say, I can see one specific exception to the phrasing above, which is that I think it would be fine for Fedora to ship a package that required non-removable DRM if-and-only-if the DRM maintenance system was also provided and available in the Fedora repositories for the user to set up themselves (rather than under the control of a third-party).
That being said, in the specific case of Mozilla Firefox, I think our first course of action here needs to be that FESCo should craft a formal letter (possibly published publicly) on behalf of the Fedora Project to the Mozilla Foundation that expresses our concern, particularly that we feel that such mandatory DRM likely causes Firefox to cease qualification as "Free Software" and thus suitability for inclusion in Fedora and likely other Free Software operating systems.
I also don't find the current situation acceptable.
Replying to [comment:10 sgallagh]: ..snip..
Before that, how about we add the firefox maintainer(s) here to comment and let us know what options are available (if any) from upstream first? Adding Martin Stransky for comment.
There are some questions which needs to be answered:
There are some scenarios and we need to make sure we understand the situation. so:
The check-sum check here is to make sure the users get the original, non-crafted extension. Do we want to disable it by default? AFAIK the gpg-check in rpm is also enabled by default and needs to be overridden by user action.
If we decide to loose the Firefox brand and ship Nightly (just because we want to ship modified extensions) I expect users may want to download branded Firefox package from mozilla directly. That may be unfortunate because Mozilla Firefox does not have Fedora mark in User Agent for instance.
Also, you say we should "finaly" unbrand Firefox. Why do we need that? Do you expect when we have such browser we'll open the package to wide audience and allow anyone to patch it? Or ship tons of local patches? I'm afraid that's a maintainers nightmare and makes the maintenance extra difficult.
Also I'm not aware of any extra patch we miss in recent Firefox in Fedora. If you want heavily patched/modified browser please use Iceweasel which is already in Fedora. IMHO it does not make sense to have two similar packages, Nightly and Iceweasel but miss Firefox.
Hi.
Which is added value of Firefox addons packaged as rpm and shipped by Fedora?
I can only comment from my point of view. I package a firefox plugin called firefox-esteidpkcs11loader. What this plugin does, is it loads appropriate opensc module into firefox and therefore users can use online banking with our national id-card. If I don't packages that plugin, then this will break user experience about esotnianidcard package. A new user will install that package which currently depends on that firefox plugin and expects everything to work. If I don't make estonianidcard package to depend on that plugin, online banking and other e-services will not work before user install manually that plugin from firefox repo.
Replying to [comment:14 stransky]:
There are some questions which needs to be answered: Which is added value of Firefox addons packaged as rpm and shipped by Fedora?
This is valuable because it allows us the ability to ship certain functionality by default that upstream Firefox may not desire (such as Fedora Workstatation-specific extensions). Futhermore, there are many users of Fedora that would not assume trust of the Mozilla Foundation that ''do'' trust Fedora because our infrastructure is public and possible to inspect. Thus, RPM-provided content may meet a business need that A.M.O does not.
When the addon is distributed by Fedora in rpm, why it needs to be modified/changed from its original state?
All RPMs distributed by Fedora must be built in the Fedora infrastructure. This is also a trust issue, as it ensures that we are building and shipping a binary that matches the sources (there's no guarantee to our users that the public source matches the binary distributed by A.M.O.). Furthermore, compiled extensions may be built with different flags in order to match the system security policy and these may differ from the upstream build.
When there's a possibility to disable addons check-sum control, should it be a default option?
In my opinion, the best solution would be for the user to be prompted the first time they start Firefox after this option becomes available and is informed similar to the following: "Firefox now supports signing add-ons. It can operate in a mode where only signed add-ons are permitted to run. This provides additional security, but may result in some of your add-ons being disabled. Do you want to turn on extension signature checking (Recommended)? Yes/No
There are some scenarios and we need to make sure we understand the situation. so: A regular user, no extra extension = OK A regular user, only official extensions from AMO = OK A regular user, original extension packaged by Fedora = OK
Right now, this doesn't exist (assuming "original extension" means the binary submitted to AMO). Or if it does, it's a non-minified JS-only add-on or similar.
A regular user, modified extension packaged by Fedora = FAILS
This is critical for Fedora's own use-case.
A developer, wants to develop/modify extensions = OK (should use a FF developer edition)
You forgot: - A user who wants to use an extension that has not been signed by Mozilla.
I don't think "Should use a FF developer edition" is an appropriate answer here. There are plenty of hobby or in-progress extensions out there from users who aren't necessarily going to jump through hoops to get Mozilla signatures.
Some sort of user decision seems more important here. Either something like what I selected above or else a manual approval of any non-signed add-on. I don't really like the individual approval idea though: it trains users to click through the dialog. An up-front security-vs-convenience choice seems like the best move.
Lastly, we ''do'' have a valid philosophical question here: mandatory signing with no option to circumvent it (short of going to a different browser) violates the principles of Freedoms 0 and 3: The freedom to run the program for any purpose. The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.
So to me, failure to have an option to circumvent the signing would be resulting in Firefox and all Firefox addons ceasing to be Free Software.
Well, we can create the unbranded Firefox version and ship it along the branded Firefox one. Only difference may be the disabled addons signing.
Please note that Mozilla is redesigning whole extension model. Binary/XPCOM extension are going to be disabled. current extensions need to be rewritten for e10s (Electrolysis). I'd wait when the situation is clearer here.
Replying to [comment:18 stransky]:
Waiting doesn't address the current concern: I'm not comfortable with Firefox rebasing to version 44 in Fedora at all without retaining an option to disable the signature-check.
One copy of the code system-wide. Same benefits as with shared libraries.
Bundled libraries, most commonly jQuery.
No, if we can somehow get our packaged extensions signed automatically. Yes otherwise.
There are some scenarios and we need to make sure we understand the situation. so: A regular user, no extra extension = OK A regular user, only official extensions from AMO = OK
Pre-built signed binaries.
A regular user, original extension packaged by Fedora = OK
That's not "original". You should say "pre-built", because built from unmodified upstream sources is just as original from my POV.
A regular user, modified extension packaged by Fedora = FAILS A developer, wants to develop/modify extensions = OK (should use a FF developer edition) The check-sum check here is to make sure the users get the original, non-crafted extension. Do we want to disable it by default? AFAIK the gpg-check in rpm is also enabled by default and needs to be overridden by user action.
Yes, but we control the signing process and it's possible for the consumer of our RPMs to rebuild them from source, sign her builds with her own key, install that key system-wide and not have to disable signature checking. That's not possible in Firefox case.
If we decide to loose the Firefox brand and ship Nightly (just because we want to ship modified extensions) I expect users may want to download branded Firefox package from mozilla directly. That may be unfortunate because Mozilla Firefox does not have Fedora mark in User Agent for instance. Also, you say we should "finaly" unbrand Firefox. Why do we need that? Do you expect when we have such browser we'll open the package to wide audience and allow anyone to patch it? Or ship tons of local patches? I'm afraid that's a maintainers nightmare and makes the maintenance extra difficult. Also I'm not aware of any extra patch we miss in recent Firefox in Fedora. If you want heavily patched/modified browser please use Iceweasel which is already in Fedora. IMHO it does not make sense to have two similar packages, Nightly and Iceweasel but miss Firefox.
I do buy the argument that I can switch to IceWeasel, but not during the life of a supported Fedora release. This should be done as a F24 change.
You broke Fedora update guidelines when you updated to FF43 in F22+ without disabling signature checking by default. IMO you should release an update with signature checking disabled and NOT update to FF44 in F22 and F23 until this is resolved. Switch to a LTS version if you have to, but do NOT break user experience.
Or do you want to ban packaging Firefox extensions in Fedora?
Btw. The latest Firefox update (43) got 8 karma almost immediately and I don't see a single bugreport in bugzilla about broken extensions. I don't feel it's a significant issue for majority of the Fedora user base.
Replying to [comment:19 sgallagh]:
Replying to [comment:18 stransky]: Please note that Mozilla is redesigning whole extension model. Binary/XPCOM extension are going to be disabled. current extensions need to be rewritten for e10s (Electrolysis). I'd wait when the situation is clearer here. Waiting doesn't address the current concern: I'm not comfortable with Firefox rebasing to version 44 in Fedora at all without retaining an option to disable the signature-check.
And what do you suggest? Another option is to remove Firefox from the distro completely (bugzilla, binaries, dependencies) and ship a new package with different name for all Fedoras. I don't think that's even possible.
Replying to [comment:22 stransky]:
[...] and I don't see a single bugreport in bugzilla about broken extensions.
Comment #1 lists two of them: 1292780 (mozilla-adblockplus) and 1292782 (mozilla-https-everywhere). I was about to open another one for mozilla-noscript, but then saw kkolfer's comment linking here, so I decided not to spam Bugzilla with yet another symptom of the same root issue...
For what it's worth, I'm in full agreement with kkolfer's statements in this ticket description -- I'm one of those users who trust the Fedora project first and foremost (due to their support of software freedoms). I would very much resent it if an upstream vendor successfully managed to implement what essentially amounts to DRM without my chosen distro offering any resistance...
Replying to [comment:23 stransky]:
And what do you suggest?
As noted above, what we suggest is that Firefox not be distributed with mandatory signature checking for extensions. Ideally, this would be patched back in upstream and maintained there, but if upstream refuses then this should become a downstream patch.
Replying to [comment:23 stransky]: And what do you suggest? As noted above, what we suggest is that Firefox not be distributed with mandatory signature checking for extensions. Ideally, this would be patched back in upstream and maintained there, but if upstream refuses then this should become a downstream patch.
Mozilla is releasing a new update (43.0.2) with extension signing disabled because of a bug there. But the plan is to enable it sooner or later so it does not change the situation.
What you suggest is not possible right now. We can ship our local downstream patches in Firefox but this one breaks main Firefox feature which should protect users. I don't expect Mozilla gives us a permission to distribute such modified package under the Firefox name.
The only option here is to ship another (unbranded) browser which may be the IceWeasel or Nightly or something which may meet your request.
Anyway, IceWeasel package is available in Fedora already so I don't see this as a big problem.
Btw. I don't believe the mandatory extension signing breaks any Fedora guideline. That check does not install any binary data, it doesn't force you to install any, it just removes support for some types of the extension. The browser works (shows web pages) without any problem.
And Fedora guidelines does not request any mandatory features for the browsers. You can just consider the extensions as removed/disabled and you're fine. For instance Epiphany also doesn't support any extensions for the Firefox package and we ship Epiphany in Fedora without any problem.
Replying to [comment:16 sgallagh]:
Lastly, we ''do'' have a valid philosophical question here: mandatory signing with no option to circumvent it (short of going to a different browser) violates the principles of Freedoms 0 and 3: The freedom to run the program for any purpose. The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits. So to me, failure to have an option to circumvent the signing would be resulting in Firefox and all Firefox addons ceasing to be Free Software.
I don't agree here. Upstream just removed a feature from the product. You're free to use it or not. You can run the browser without such feature for any purpose. You can also modify it and distribute it (just use a different name).
You can't talk about freedom and force people to support/provide features you request. As I said, I don't see any single line in the guidelines which request that browser must support this and those extension and features.
Consider it as a removed feature, which it actually is.
Replying to [comment:29 stransky]:
[...]
I don't see any single line in the guidelines which request that browser must support this and those extension and features. Consider it as a removed feature, which it actually is.
I don't see any single line in the guidelines which request that browser must support this and those extension and features.
According to our package update policy in stable releases (https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases):
Package maintainers MUST:
So if you can't disable add-on signing, please switch to the ESR release which won't have it until December 2016.
You can do (almost) whatever you want in rawhide, but please do NOT remove features in stable releases.
Replying to [comment:27 stransky]:
I looked for IceWeasel under:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/i/
but couln't find it there. Could you please post a link? At this point trying it out might turn out to be a good idea, just in case... :)
Do you mean to say icecat actually?
Replying to [comment:30 rathann]:
According to our package update policy in stable releases (https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases): Package maintainers MUST: [...] Avoid changing the user experience if at all possible. So if you can't disable add-on signing, please switch to the ESR release which won't have it until December 2016. You can do (almost) whatever you want in rawhide, but please do NOT remove features in stable releases.
Sure, I don't want to break the user experience, but I don't see any alternative right now. Unfortunately the next ESR release (45) is going to have this check also enabled. ESR 45 is going to be shipped on February 2016.
And sorry, it's really IceCat package (https://apps.fedoraproject.org/packages/icecat).
Replying to [comment:34 stransky]:
Replying to [comment:30 rathann]: According to our package update policy in stable releases (https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases): Package maintainers MUST: [...] Avoid changing the user experience if at all possible. So if you can't disable add-on signing, please switch to the ESR release which won't have it until December 2016.
According to our package update policy in stable releases (https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases): Package maintainers MUST: [...] Avoid changing the user experience if at all possible. So if you can't disable add-on signing, please switch to the ESR release which won't have it until December 2016.
I meant "it won't have it unconditionally enabled".
You can do (almost) whatever you want in rawhide, but please do NOT remove features in stable releases. Sure, I don't want to break the user experience, but I don't see any alternative right now. Unfortunately the next ESR release (45) is going to have this check also enabled. ESR 45 is going to be shipped on February 2016.
Sure, but according to https://wiki.mozilla.org/Addons/Extension_Signing you'll still be able to turn it off, which is what we want here:
{{{ The first ESR version to support signing will be Firefox ESR 45. The current plan is to have ESR work like 40-42, with a preference that can turn off enforcement, but that may change in the future. }}}
I've gotten one against mozvoikko, which is not working currently: https://bugzilla.redhat.com/show_bug.cgi?id=1292775
Although, if Mozilla is planning to disable binary extensions, I guess we're out of luck anyway. I'll try to discuss this upstream when I have the time.
Replying to [comment:36 vpv]:
Replying to [comment:22 stransky]: Btw. The latest Firefox update (43) got 8 karma almost immediately and I don't see a single bugreport in bugzilla about broken extensions. I don't feel it's a significant issue for majority of the Fedora user base. I've gotten one against mozvoikko, which is not working currently: https://bugzilla.redhat.com/show_bug.cgi?id=1292775
FWIW, I didn't get any bugzilla reports about mozilla-noscript not working, but I did get a +1 in bodhi on my mozilla-noscript update saying that it's working AGAIN, so I'd count that as one: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c6f49d6f0f
shouldn't Fedora distribute Firefox as intended by upstream, but also package the official unbranded version they talk about (without addon signing)? I personally like the addon signing, but I can see others not liking it. I wonder what the name of the unbranded version would be.
I believe this ticket is invalid because Add-on signing has nothing to do with DRM and does not break any Fedora rules. We may focus to the alternative browser (IceCat or something else) which will support the unsigned extensions.
I think you also see the Firefox removal from Fedora does not serve anything. We can't use that name for different browser and we can't ship our unbranded browser under that name.
So the only solution here is to keep the recent Firefox package (no need to remove it) and provide also a different one with enabled all extensions.
Thinking about this some, I find this fairly analogous to signed kernel modules. For security purposes, during the kernel build all modules are signed by an ephemeral key. That means that one cannot install a Fedora kernel and sign an out of tree module with the same key. If a different key is used, the kernel will refuse to load that module. We do allow completely unsigned modules to be loaded, but only if the machine is not in Secure Boot mode.
One could download the kernel source and either rebuild the kernel without signed modules or rebuild the kernel with a persistent key and sign their modules with that as well, however that isn't something Fedora is doing. That would be the end user. The same thing can be done with Firefox source if a user chooses.
So if we go with Firefox extensions being analogous to kernel modules, in that they are both external modifications of the software in question, I don't see how the scenarios differ. One could argue that an errant kernel module can bring down the whole machine, whereas an errant Firefox extension could only crash Firefox, but I don't think that is that far removed from "whole machine" for a wide number of users. (Also, an errant Firefox extension could lead to CVEs where user data is leaked, etc)
Does anyone find my analogy to be inaccurate?
Replying to [comment:42 jwboyer]:
Yes, there's one piece you're missing: we don't ship out-of-tree kernel modules as separate packages in Fedora, but we ''do'' ship numerous Firefox extensions that way (and have for many years). In fact, we have discussed shipping some of them enabled by default for the Workstation Edition (the user-agent extension and possibly some theming).
By switching to a signature model that we don't control, we lose the ability for Fedora to ship any modifications to Firefox at all to make it fit better with our operating system. If upstream believes that this signing is critical to their security model, then it should be modified to allow additional trusted signing keys to be added (similar to how we have support for many certificate authorities). Then Fedora-provided extensions could be signed with a Fedora CA.
Replying to [comment:43 sgallagh]:
Replying to [comment:42 jwboyer]: Does anyone find my analogy to be inaccurate? Yes, there's one piece you're missing: we don't ship out-of-tree kernel modules as separate packages in Fedora, but we ''do'' ship numerous Firefox extensions that way (and have for many years).
Yes, there's one piece you're missing: we don't ship out-of-tree kernel modules as separate packages in Fedora, but we ''do'' ship numerous Firefox extensions that way (and have for many years).
Fair point, though I'm sure upstream mozilla feels much the same way as we do about out-of-tree things. :)
In fact, we have discussed shipping some of them enabled by default for the Workstation Edition (the user-agent extension and possibly some theming).
That seems like it should be put on hold regardless of this discussion given that mozilla is rewriting the whole extension mechanism.
I have no issues with this, but it depends on upstream actually implementing the functionality. That seems unlikely, but even if it does happen it wouldn't be done soon. If you're waiting for this, then you might as well wait for the extension framework rewrite too. And if we're waiting for both things, I'd question the utility of packaging extensions in Fedora itself because the existing packages won't work anyway. It might be better to submit the extensions we are interested in including as official AMO signed extensions.
I'm not saying a downstream patch for the toggle is a bad idea at all, but if upstream Firefox does not approve it then we're forced into:
So by all means pursue the toggle but I think we need to have a clear plan for both the immediate situation and the longer-term future.
Replying to [comment:44 jwboyer]:
Replying to [comment:43 sgallagh]: [...] By switching to a signature model that we don't control, we lose the ability for Fedora to ship any modifications to Firefox at all to make it fit better with our operating system. If upstream believes that this signing is critical to their security model, then it should be modified to allow additional trusted signing keys to be added (similar to how we have support for many certificate authorities). Then Fedora-provided extensions could be signed with a Fedora CA. [...] So by all means pursue the toggle but I think we need to have a clear plan for both the immediate situation and the longer-term future.
Replying to [comment:43 sgallagh]: [...]
By switching to a signature model that we don't control, we lose the ability for Fedora to ship any modifications to Firefox at all to make it fit better with our operating system. If upstream believes that this signing is critical to their security model, then it should be modified to allow additional trusted signing keys to be added (similar to how we have support for many certificate authorities). Then Fedora-provided extensions could be signed with a Fedora CA. [...] So by all means pursue the toggle but I think we need to have a clear plan for both the immediate situation and the longer-term future.
I use the Mozilla addons packaged in Fedora rather than addons from AMO for the same reasons I use the Emacs extensions packaged in Fedora rather than those coming from MELPA or marmalade, and these reasons are the same as the reasons I install Python libraries with DNF instead of pip or easy_install, and again I do that for the same reasons as the reasons I use GNOME shell extensions packaged in Fedora rather than those from extensions.gnome.org.
The reasons are:
What would Fedora do if Emacs was modified upstream so that only packages from elpa.gnu.org could be installed, with no possibility to add other package sources like MELPA and marmalade, or to use the extensions packaged in Fedora? Let's ask the same question about gnome-shell.
The difference is that Mozilla would not allow Fedora to modify the browser and keep the branding. This is (part of) the reason Debian has Iceweasel, GNU has !IceCat and gNewSense had !BurningDog. Fedora can make !IceCat the default browser in Workstation instead of Firefox, or can wait until Mozilla releases the unbranded versions of Firefox and make that the default instead. Having a Fedora CA able to sign the extensions would be nice, if (?) upstream can provide that.
Replying to [comment:45 rvernon]:
Replying to [comment:44 jwboyer]: Replying to [comment:43 sgallagh]: [...] By switching to a signature model that we don't control, we lose the ability for Fedora to ship any modifications to Firefox at all to make it fit better with our operating system. If upstream believes that this signing is critical to their security model, then it should be modified to allow additional trusted signing keys to be added (similar to how we have support for many certificate authorities). Then Fedora-provided extensions could be signed with a Fedora CA. [...] So by all means pursue the toggle but I think we need to have a clear plan for both the immediate situation and the longer-term future. I use the Mozilla addons packaged in Fedora rather than addons from AMO for the same reasons I use the Emacs extensions packaged in Fedora rather than those coming from MELPA or marmalade, and these reasons are the same as the reasons I install Python libraries with DNF instead of pip or easy_install, and again I do that for the same reasons as the reasons I use GNOME shell extensions packaged in Fedora rather than those from extensions.gnome.org. The reasons are: I trust Fedora, while I do not necessarily trust extensions coming from another website. I can have all software on my system upgraded with a DNF command instead of having each software have its own way of upgrading its extensions. I can get information about packages, remove them, etc. with DNF. I can report bugs about extensions on the Fedora issue trackers. I only get new versions of software once they are stable, and if they meet the Fedora policies.
Yes, those all boil down to convenience and trust. They describe exactly why a distro exists to begin with. (I would argue even your first bullet is about convenience rather than trust, given that the sources for the extensions you install from Fedora are all downloaded from other websites and you are relying on a Fedora maintainer do the vetting for you.)
That is essentially the question we are asking, yes. The existence of signed software going forward in the future is something I believe will be increasingly common. The interactions with it are interesting to work out.
The difference is that Mozilla would not allow Fedora to modify the browser and keep the branding. This is (part of) the reason Debian has Iceweasel, GNU has IceCat and gNewSense had BurningDog. Fedora can make IceCat the default browser in Workstation instead of Firefox, or can wait until Mozilla releases the unbranded versions of Firefox and make that the default instead.
Yes, those are things which fall into the last bullet of my listed options above. However, choosing that isn't something to be done lightly. Firefox is one of the most successful brands in the tech industry and has a lot of marketing impact, arguably more than the Fedora brand itself. To suddenly no longer be able to distribute a Firefox branded browser doesn't mean users won't have access to the browser technology, but it does mean we'd have to explain why they can't find/run "firefox" and how icecat (or whatever) is really the same thing, etc etc.
Having a Fedora CA able to sign the extensions would be nice, if (?) upstream can provide that.
Nobody is disagreeing with that, though there are other significant issues to weigh when considering to become a CA.
I would like to make several proposals for FESCo to consider, rework, etc.:
Proposal 1) FESCo forbids the change of behavior in stable, released Fedora. Implementation-wise, this means that Fedora 23 and older will switch to the Firefox ESR version 45 when it is released in February, which retains the option to disable the mandatory signature check. (Ideally, the RPM default will be to have it disabled, but if Mozilla forbids this then I'll settle for a Common Bugs entry on how to disable it.)
Proposal 2) FESCo will draft a letter to the Mozilla Foundation requesting that they implement[*] one of the following solutions: 1. Firefox does not mandate signature checking for system-installed extensions (justification: only root can install these and already has ultimate power to bypass checking by installing an alternative Firefox build) 1. Firefox adds the ability to add and remove the signing authorities that the signature checking will accept. Fedora can then add its own CA to the list. 1. Firefox retains the option to disable signature checking for extensions. (Optionally, an argument could be made for this to be configurable only by root and not by individual users.)
[*] "Implement" could mean "agree to accept a patch if we help provide one".
Replying to [comment:47 sgallagh]:
I would like to make several proposals for FESCo to consider, rework, etc.
I think we should definitely go the 2) path and try to communicate with Mozilla, don't think it's something that needs to be solved over night. I don't agree with the original statement that it violates the software freedoms and hence the license. And if we base a decision on it, we should seek a legal advice first. I've also failed to find how specifically it breaks rules of Fedora.
I agree that 3rd-party signing enforcing in general is an important thing to solve, but removing Firefox from Fedora or sticking with ESR is not going to improve this particular case. IceCat is already in Fedora and anyone for whom the new policy of Mozilla doesn't work can use it. But there are many users who simply want to use Firefox (it's one of the strongest brands in open source) and don't mind the new policy and we'd remove the choice to use it or use it in the latest version (in my opinion sticking with ESR goes against the nature and foundations of Fedora) frome them. Yes, some products or spins may change their choice of the default browser to IceCat or something else, but that should be their decision.
So I'd humbly propose to FESCo: 1. begin a communication with Mozilla, 2. keep Firefox as it is for now, 3. share with users (common bugs,...) that they can use addons shipped by Fedora in IceCat instead, in addition we can look into packaging Firefox Developer Edition where signed addons are not enforced, too, so that there would be an option from Mozilla directly.
I would like to make several proposals for FESCo to consider, rework, etc.: Proposal 1) FESCo forbids the change of behavior in stable, released Fedora. Implementation-wise, this means that Fedora 23 and older will switch to the Firefox ESR version 45 when it is released in February, which retains the option to disable the mandatory signature check. (Ideally, the RPM default will be to have it disabled, but if Mozilla forbids this then I'll settle for a Common Bugs entry on how to disable it.)
I am neither for or against this proposal at the moment. I need more time to consider it.
Proposal 2) FESCo will draft a letter to the Mozilla Foundation requesting that they implement[*] one of the following solutions: 1. Firefox does not mandate signature checking for system-installed extensions (justification: only root can install these and already has ultimate power to bypass checking by installing an alternative Firefox build) 1. Firefox adds the ability to add and remove the signing authorities that the signature checking will accept. Fedora can then add its own CA to the list. 1. Firefox retains the option to disable signature checking for extensions. (Optionally, an argument could be made for this to be configurable only by root and not by individual users.) [*] "Implement" could mean "agree to accept a patch if we help provide one".
I'd suggest including all of those options in communication with Mozilla. The more options FESCo presents as acceptable to Fedora, the greater chance we have at actually getting something we would like to see.
We also need to be prepared if this communication with Mozilla fails. Do you have suggestions on that?
Replying to [comment:49 jwboyer]:
Replying to [comment:47 sgallagh]: I'd suggest including all of those options in communication with Mozilla. The more options FESCo presents as acceptable to Fedora, the greater chance we have at actually getting something we would like to see.
Sorry, my wording above was unclear. I was actually intending to propose that such a communication included all of those as possible solutions, not that we choose only one to suggest. So I agree completely.
Well, the Proposal 1 above is at least a mechanism for gaining time while we make that decision. I'd like to believe that this can be resolved diplomatically, but in an absolute worst case, we can always elect to switch to Icecat (possibly just named "Browser" in Workstation?) as our default web browser offering.
ESR 45 release in Fedora only buys 6 months before next ESR (53) which would have the extension signing enabled as the standard release. It may just break the extensions later, in middle of Fedora 24 lifetime or so. Also update from 45 to 53 in standard Fedora my be disruptive. Stay on ESR 45 may make sense only on Fedoras which comes EOL before ESR 53 release (Fedora 22/23?).
(justification: only root can install these and already has ultimate power to bypass checking by installing an alternative Firefox build)
That's incorrect. Firefox also launches extensions from your Firefox profile which can be everywhere (usually ~/.mozilla) and it has to be writable by user. Theoretically a broken/hacked browser may download/install any extension and store it in the profile. Also any other application running with user privileges can do that.
You may say that when you can broke the browser you can do anything. That may be true but the extensions are the simplest way how to hack anything and this change can't be detected by rpm (rpm -V firefox) and it survives package update.
Replying to [comment:50 sgallagh]:
Mozilla has a numbers from Firefox userbase which says that only a fraction of users has any addons installed and the most used one is usually Add block. Do we have any numbers how many people actually using the fedora-packaged extensions? According the bugreports there's only a few of them.
Replying to [comment:51 stransky]:
Replying to [comment:47 sgallagh]: (justification: only root can install these and already has ultimate power to bypass checking by installing an alternative Firefox build) That's incorrect. Firefox also launches extensions from your Firefox profile which can be everywhere (usually ~/.mozilla) and it has to be writable by user. Theoretically a broken/hacked browser may download/install any extension and store it in the profile. Also any other application running with user privileges can do that.
You misunderstand; I'm saying that extensions located in the profile directory could still have signatures enforced, but ones launched from the system directory could (optionally) skip it.
i dont see this conversation really going anywhere. but whats Fesco's plans when Firefox 44 is released? to F23, i dont think IceCat is a Great answer to solving this problem. there's to many users that use Firefox due to its Extensions.
Replying to [comment:55 greg18]:
i dont see this conversation really going anywhere. but whats Fesco's plans when Firefox 44 is released? to F23, i dont think IceCat is a Great answer to solving this problem.
When the Firefox 44 is released it's going to be shipped in Fedora as a regular update. There's no reason to hold that release, it fixes security bugs and so. And also it does not violate any Fedora rules.
there's to many users that use Firefox due to its Extensions.
How many users are using the Fedora-packed extensions? Do you have any numbers? According to bugzilla activity I see only 3-4 people complaining about it in Firefox 43.
Replying to [comment:53 sgallagh]:
That sounds reasonable but it's long-term issue in the official Firefox release.
BTW. There's Mozilla API for the extension signing:
http://olympia.readthedocs.org/en/latest/topics/api/signing.html
could it be incorporated to our build process to sign binary extension after its build in koji?
Since there's an easy workaround for FF 43 (which is mentioned in the bugs for mozilla-adblockplus and mozilla-https-everywhere) people aren't likely to complain until it stops working.
Replying to [comment:59 robatino]:
How many users are using the Fedora-packed extensions? Do you have any numbers? According to bugzilla activity I see only 3-4 people complaining about it in Firefox 43. Since there's an easy workaround for FF 43 (which is mentioned in the bugs for mozilla-adblockplus and mozilla-https-everywhere) people aren't likely to complain until it stops working.
Maybe. But more likely people just install extensions directly in about:addons inside Firefox rather than search for corresponding rpm package(s). Also most how-to suggest to install extensions here and that works on all systems.
I personally don't know anyone who uses Fedora rpm extensions. So it would be great to have some numbers - is there any possibility to get at least rough estimate how frequent that packages are?
Replying to [comment:56 stransky]:
Replying to [comment:55 greg18]: i dont see this conversation really going anywhere. but whats Fesco's plans when Firefox 44 is released? to F23, i dont think IceCat is a Great answer to solving this problem. When the Firefox 44 is released it's going to be shipped in Fedora as a regular update. There's no reason to hold that release, it fixes security bugs and so. And also it does not violate any Fedora rules. there's to many users that use Firefox due to its Extensions. How many users are using the Fedora-packed extensions? Do you have any numbers? According to bugzilla activity I see only 3-4 people complaining about it in Firefox 43.
nope i dont have any numbers, but i dont use or nore will i use Fedora Packaged Extensions. if i need a workaround to some Mozilla firefox issue, i know where to go an find a solution to it
Replying to [comment:60 stransky]:
No.
We have no system in place to track this information on local systems, and since we send users to mirrors for all package downloads (and most users use metalinks where we only know they have yum/dnf installed, not even if they use it or if they want to search or install packages), there is no way we can determine how often a package is used.
Also, I am not convinced that the number of bugzilla reports is a fair indication of number of users of the package either: there are enough people that never find bugzilla but ask for help elsewhere on the internet.
Also, you say we should "finaly" unbrand Firefox. Why do we need that? Do you expect when we have such browser we'll open the package to wide audience and allow anyone to patch it? Or ship tons of local patches? I'm afraid that's a maintainers nightmare and makes the maintenance extra difficult. Also I'm not aware of any extra patch we miss in recent Firefox in Fedora.
Just a few that come to my mind, that have come up in the past and are still relevant: the KDE integration patch that openSUSE developed and that all the other distributions that support KDE are shipping, removing the ads Mozilla added recently, * unbundling more bundled libraries. There are probably more. In addition, Firefox (and its dependency xulrunner) are the '''only''' packages in the entire Fedora that are not open to provenpackager commits.
If you want heavily patched/modified browser please use Iceweasel which is already in Fedora.
As was pointed out later in the thread, what we have is actually GNU !IceCat, not "Iceweasel". !IceCat is not just a rebranded Firefox like a Debian-style "Iceweasel" package would be, but has other significant changes, and last I checked also significantly lagged behind upstream Firefox.
Thinking about this some, I find this fairly analogous to signed kernel modules. For security purposes, during the kernel build all modules are signed by an ephemeral key. That means that one cannot install a Fedora kernel and sign an out of tree module with the same key. If a different key is used, the kernel will refuse to load that module. We do allow completely unsigned modules to be loaded, but only if the machine is not in Secure Boot mode. One could download the kernel source and either rebuild the kernel without signed modules or rebuild the kernel with a persistent key and sign their modules with that as well, however that isn't something Fedora is doing. That would be the end user. The same thing can be done with Firefox source if a user chooses. So if we go with Firefox extensions being analogous to kernel modules, in that they are both external modifications of the software in question, I don't see how the scenarios differ. One could argue that an errant kernel module can bring down the whole machine, whereas an errant Firefox extension could only crash Firefox, but I don't think that is that far removed from "whole machine" for a wide number of users. (Also, an errant Firefox extension could lead to CVEs where user data is leaked, etc) Does anyone find my analogy to be inaccurate?
So IMHO, it is totally wrong to use this as a precedent to allow even more freedom-destroying DRM schemes in Fedora.
This is exactly why we need Firefox rebranded! It keeps getting a free pass out of any and all of our policies because "upstream doesn't allow us to fix it". I'm totally fed up of this nonsense.
We are simply asking you to: 1. File a package rename request from firefox to iceweasel (or some other name that's not firefox, to avoid conflicts with Debian). 2. Add Obsoletes: firefox and Provides: firefox to the new package. There is precedent that this is '''not''' considered a trademark violation. 3. Make that package actually comply with Fedora policies.
Obsoletes: firefox
Provides: firefox
If you refuse to do this, the package needs to be maintained by somebody willing to do it.
Firefox ESR is not a long-term solution (because upstream can and probably will do the same kind of silly things in there).
Option 1. does not really solve the issue of user-installed extensions: they'd be installable only by root, and not through the normal mechanisms provided by the browser. It only really helps for the special case of our extension RPMs. Option 2. only empowers the user if they can add keys at runtime, not just we can add them at compile-time, and even then, it's a huge hoop to jump through for just getting extensions to run (and also breaks installing them through the normal mechanisms in the browser). See also my stance on Restricted Boot. Only option 3. is really acceptable, but I don't have high hopes in upstream cooperating there.
I think in the end there is no alternative to rebranding, and it would solve also any other present and future issues we have with Firefox (because we would finally be able to just modify it if it does not work the way we want it to). Attempting to compromise with this uncooperative upstream will not lead to an acceptable solution.
When the Firefox 44 is released it's going to be shipped in Fedora as a regular update.
No thanks for this blatant disregard of both your users' freedom and the update policies. (Read what rathann explained: Updates to a stable release '''must not''' remove features.)
This is why FESCo needs to urgently act and block that update until a solution is found (which is most likely a rename – and no, a rename is not forbidden by the update policies if there is a clear upgrade path through Obsoletes / Provides in place).
And what rebranding would also allow us is backporting security fixes so that we are not always forced to upgrade to the latest version even when it contains changes that violate our update policies, or alternatively, to revert the offending changes when it makes sense (e.g., if it's just a boolean flag).
Introducing such a signature check by default, for example, '''is''' a blatant violation of the update policies. According to the policies, it can be enabled by default only in Rawhide! (And for other reasons, pointed out in the message that started this thread, it must be possible to turn it off everywhere.) But there were also other major disruptive changes that got pushed as part of "security updates" in the past, such as a major UI redesign that totally goes against both the letter and the spirit of our update policies. The change to hide "http://" by default was also such a change. All these are examples of changes that are '''not''' acceptable in an update to a stable release ('''especially''' a security update).
http://
We expect all other maintainers to exercise this kind of discretion before blindly updating to a newer upstream release. I really don't see why Firefox keeps getting a free pass just because it's Firefox. This actively hurts the quality of our entire distribution.
Agreed with Kevin Kofler, Fedora needs to replace the Firefox browser by a rebranded or unbranded browser to be able to make changes. Debian has Iceweasel, gNewSense has !BurningDog, Trisquel has a generic unbranded browser and GNU has !IceCat. Unfortunately Mozilla did not release an unbranded version of Firefox yet, it would be nice to use that instead of Fedora making its own browser or using one of those made by other distributions.
Reasons to do this include being able to backport security updates and bug fixes to a stable release without bringing an entire new upstream release that introduces major features, making it possible for spins to customize the browser, adding Fedora branding (if desired), making Fedora-packaged addons work... there are enough reasons that show it is necessary, so let's do it.
Replying to [comment:64 kkofler]:
You're right, it follows ESR like Debian's Iceweasel. Fedora wants to be the First to have new Features in new releases, and that wouldn't work since ESR doesn't match Fedora's release cycle.
Replying to [comment:68 rvernon]:
Agreed with Kevin Kofler, Fedora needs to replace the Firefox browser by a rebranded or unbranded browser.
Guys, if you need such browser, you're free to submit your own unbranded, crafted, hacked "whatever you want" package. You also can choose your own name and that package can happily coexist with official Firefox, Web, IceCat and other web browsers available in Fedora. And if your package get enough audience and quality it can be also an official Fedora browser.
But don't say we can't ship original branded Firefox package in Fedora. That statement is a nonsense, FUD and does not have any support in Fedora policies.
Kevin, please tone it down a bit. While I agree with some of what you are saying, your methods are actively working against your goals.
To clarify my proposals above, those weren't alternatives. Proposal 1) was just meant to be a short-term solution (or one for F22/F23) to give us a few months to work out a better long-term solution (which I chose to describe as asking upstream if they would be willing to implement one of those three choices).
I think that a more constructive approach to the problem here is for us to engage with upstream and express that we have some concerns about this signature checking and propose some ''reasonable'' mechanisms for addressing it.
I am aware of the problems that upstream wants to solve with the signature checking; they want to help users avoid malware and ensure that they get only trusted extensions installed on their systems. This is a significant improvement for users. However, my primary concern is that in doing so, they make two faulty assumptions: * The Mozilla Foundation is the only trustworthy source for extensions. * All end-users of Firefox implicitly trust Mozilla
I'll address these assumptions individually.
As we have noted elsewhere in this thread, there are valid reasons why Fedora (or any other distribution that ships Firefox) might want to ship an extension installed in the system path. Some of the cited examples might be * Shipping a security-enhancing extension like "HTTPS Everywhere" by default * Providing distro-specific enhancements, such as an extension to connect the password store with a keyring or interacting with something like GNOME Online Accounts to automatically log into certain web services.
The second assumption is a bit harder to explain. Mozilla appears to be assuming that if a user is running Firefox at all, it means that they must trust Mozilla in everything. (Given how much of a user's computing life is spent in the browser, there may be a certain degree of truth in that, admittedly.) However, the existence of extensions in the first place implies that Mozilla also knows that what it ships is not exactly what all of its users want. All add-ons that are provided on AMO must go through a complicated review process. To Mozilla's credit, they are [[https://developer.mozilla.org/en-US/Add-ons/AMO/Policy/Reviews|quite thorough]] in explaining what the review process entails (making this process far more transparent than many other similar services). However, they also list certain actions that they forbid that we might want to be able to provide. In particular, add-ons listed on AMO are specifically required to "Appeal to a general audience", which might conflict with the example above for distro-specific integration.
Also, there is no guarantee that the requirements for extension review will not change over time. (In fact, it's quite likely that they will get more restrictive over time in an attempt to combat a changing malware ecosystem.)
So, I still feel that my proposal 2) above is at least worth exploring as a means of addressing some of these concerns. I think talk of swapping out the default browser in Fedora is premature; threatening ultimatums is an excellent way of ruining any chance we might have of negotiating a mutually-acceptable solution here.
I am +1 for Proposal 2. It makes sense, and it is a good idea to start that conversation now. I don't believe we really need to wait for full FESCo approval either, but we can if others wish.
I am -1 for Proposal 1.
Replying to [comment:70 sgallagh]:
Are they really? I really have only one goal: Make the primary browser in Fedora comply to the same goals and policies as all other packages in Fedora. Of those, "Freedom" is even one of the 4 keywords.
I think your suggested approach of dialoging with upstream is naïve and will ultimately not lead anywhere. Even stransky does not believe upstream is willing to budge even an inch on the issue. And in the unlikely event they do, it will inevitably be a compromise and not what we really need (signature checks need to be completely disabled on Fedora). The discussion will only cost us time, during which stransky will be trying to create hard facts by simply importing Firefox 44 as is. Firefox 44 is round the corner, FESCo needs to act to block that update '''now'''.
Mozilla upstream's goals have never really aligned to ours, and it has become worse and worse all the time. You really need to accept that we have distinct goals and that we cannot just ship an unpatched Firefox. And as Mozilla is threatening anybody who patches Firefox in a way they don't like with a trademark lawsuit, a rebranding is ultimately unavoidable.
It is Mozilla who is threatening ultimatums, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622 . This nonsense needs to stop, and the only way we can stop it is to stop using the encumbered name.
https://mozilla.aha.io/published/0d49e74c6853d3d721010bd9d4f67f34?page=2 Firefox47 to Mandate Signature signing
Replying to [comment:72 kkofler]:
Replying to [comment:70 sgallagh]: Kevin, please tone it down a bit. While I agree with some of what you are saying, your methods are actively working against your goals. Are they really? I really have only one goal: Make the primary browser in Fedora comply to the same goals and policies as all other packages in Fedora. Of those, "Freedom" is even one of the 4 keywords.
The Freedom foundation reflects the licensing we choose for the software we included in the distribution. As Firefox is distributed under the MPL, it is free software. A user may download the code, modify it, build it, and use it. They may also redistribute their modified work as long as they adhere to the trademark guidelines Mozilla has set forth.
There is nothing that is non-free about the browser, either in its current form or in any other form we should choose to ship it in as long as it is licensed under the MPL.
Replying to [comment:73 greg18]:
I think that roadmap is outdated. The release dates also do not match reality.
Replying to [comment:74 jwboyer]:
Replying to [comment:72 kkofler]: Replying to [comment:70 sgallagh]: Kevin, please tone it down a bit. While I agree with some of what you are saying, your methods are actively working against your goals. Are they really? I really have only one goal: Make the primary browser in Fedora comply to the same goals and policies as all other packages in Fedora. Of those, "Freedom" is even one of the 4 keywords. The Freedom foundation reflects the licensing we choose for the software we included in the distribution. As Firefox is distributed under the MPL, it is free software. A user may download the code, modify it, build it, and use it. They may also redistribute their modified work as long as they adhere to the trademark guidelines Mozilla has set forth.
But a user cannot exercise those freedoms when it comes to extensions for the browser, unless he/she replaces the entire browser, but then you can argue that IE is "Free Software" because you can replace it with Firefox / Chromium / Konqueror / !QupZilla / Epiphany / whatever (which of course doesn't make sense). Firefox as distributed will be actively impeding the user from exercising the FSF's Four Freedoms.
See above, but in addition, the logo is under a non-Free copyright license (which was what forced Debian to rebrand back in 2006). Whether the logo qualifies as Content under https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content and whether the "license" (http://lxr.mozilla.org/mozilla/source/other-licenses/branding/firefox/LICENSE – "You are not granted rights or licenses to the trademarks of the Mozilla Foundation or any party, including without limitation the Firefox name or logo.") qualifies as "open source compatible" is debatable. If either or both are not the case, then the logo must go away, and according to the Debian discussion, the name too.
I think that a more constructive approach to the problem here is for us to engage with upstream
I think this would be the optimal path forward. If we rename Firefox, both Fedora and Mozilla lose a bit (we are worse off because our users are confused, Mozilla because they have less apparent users who might not even know they are using Firefox, the brand is weakened). The problem that upstream is trying to solve with signature checking applies also to our users. It seems that malware/adware/spyware is less frequent on Linux, but it exists and we should put up as many defences as possible. So I disagree with Kevin when he says that we should disable signature checking altogether.
Various people have stated that the hardening features introduced in Firefox go against our principles. But nobody said specifically how. What Stephen writes about not trusting the upstream totally hits very close to the mark. We try to cooperate very closely with upstreams, but users trust the distribution, and the administrator (root) can override anything. The owner of the machine has the freedom to modify it in any way technically feasible and change who is trusted at any time. Changes in Firefox go against this, because they are make those changes of functionality and trust by the owner of the machine much more cumbersome, requiring at least a recompile.
Proposal 2) FESCo will draft a letter to the Mozilla Foundation requesting that they implement one of the following solutions: Firefox adds the ability to add and remove the signing authorities that the signature checking will accept.
Proposal 2) FESCo will draft a letter to the Mozilla Foundation requesting that they implement one of the following solutions:
Let's limit this to system wide locations (i.e. require root privileges). This would preserve the goal of protecting users in case they are duped into installing an untrustworthy extension, while preserving the freedom of admin modifications.
Firefox retains the option to disable signature checking for extensions.
This comes too close to defeating the protection, leaving everything in the hands of an unprivileged user. I don't think we should try to pursue that.
Firefox does not mandate signature checking for system-installed extensions
We could implement signing by our own trust anchor for distro packages. It would require extra work for the distro, without too much benefit to users, but I think we could live with it. I'd qualify part 1. as nice-to-have.
I think FESCo should indeed write a letter to Mozilla to pursue 2.2 (for root only) and possibly 2.1. It's a role for FESCo (maybe in cooperation with the council), because it should be clear the the project as a whole is represented.
Administrator freedom is important, but it's not something that is often explicitly mentioned. I think that this is because of technical reasons: it's really hard to limit what root can do. The fact that the distribution can filter what upstreams provide is only possible because we are working with free software. For the same reason, it's really rare to even attempt to implement limitations in free software because either the upstream or users will remove them. This is one of those rare cases, trademark law being used to reach down and constrain local modifications.
Various people have stated that the hardening features introduced in Firefox go against our principles. But nobody said specifically how.
I did: It stops the user from exercising the Four Freedoms: http://www.gnu.org/philosophy/free-sw.html
All 4 freedoms are impeded by the mechanism!
And let me also quote http://www.gnu.org/philosophy/loyal-computers.html :
A feature to check for signatures on the programs that run is compatible with this principle provided the signature checking is fully under the user's control. When that is so, the feature helps implement the user's decisions about which programs to run, rather than thwarting the user's decisions. By contrast, signature checking that is not fully under the user's control violates this principle.
Firefox's signature checking is very blatantly "not fully under the user's control".
I would also like to point out that not even Google is enforcing such a restrictive policy, they are only restricting installation of extensions in the proprietary Chrome (not in Chromium), and even that only on Windows and Mac.
Replying to [comment:78 kkofler]:
Various people have stated that the hardening features introduced in Firefox go against our principles. But nobody said specifically how. I did: It stops the user from exercising the Four Freedoms: http://www.gnu.org/philosophy/free-sw.html All 4 freedoms are impeded by the mechanism!
Sorry, Kevin. I think this statement is overstated, but there's a worthwhile discussion to be had here. I'll go in order (and cite from that exact page):
So I guess my dilemma here is this: I can't find any strong argument to assert that Firefox itself is no longer Free Software, but it does seem to me that its actions serve to force extensions to not be Free Software. I personally am not terribly comfortable with this precedent.
I see even Freedom 0 as not satisfied: You have an extension, you want to run it, Firefox won't let you. How's that different from the Tivo, which is cited as a negative example by the FSF?
Replying to [comment:80 kkofler]:
The FSF created an entirely new license to, in part, deal with the "tivo-ization" issues. Firefox is not distributed under GPLv3. The license it is distributed under is not breached in any way.
You are trying to construe something you do not like as being a violation of the software license. It is not a violation. It is an inconvenience to users wishing to do something the authors of the software do not wish to allow, which is within the author's rights. Similarly, the license allows you to modify the software to remove that section of code. All parameters of the license are met for both parties. Further, some users may wish to utilize this feature provided by Firefox and blocking its inclusion in Fedora would be inconveniencing those users but still within Fedora's purview to do so even though there is no license violation.
The situation at hand requires compromise and taking all factors into account. The world is not black and white. Your points around convenience may be valid, but your continued attempts to elevate this into an issue of Freedom are doing nothing but discrediting yourself. As Stephen has suggested, you would likely make more progress if you stop being disingenuous and focus on the impacts you seek to remedy without resorting to drama and hyperbole.
I am not construing it as a violation of the software license (at least not the letter of the license). I never claimed otherwise. That is a strawman. I am construing it instead as a violation of the core principles of Free Software and thus of the commitment to freedom Fedora has in its core values.
Replying to [comment:72 kkofler]: Replying to [comment:70 sgallagh]: Kevin, please tone it down a bit. While I agree with some of what you are saying, your methods are actively working against your goals. Are they really? I really have only one goal: Make the primary browser in Fedora comply to the same goals and policies as all other packages in Fedora. Of those, "Freedom" is even one of the 4 keywords. The Freedom foundation reflects the licensing we choose for the software we included in the distribution. As Firefox is distributed under the MPL, it is free software. A user may download the code, modify it, build it, and use it. They may also redistribute their modified work as long as they adhere to the trademark guidelines Mozilla has set forth. There is nothing that is non-free about the browser, either in its current form or in any other form we should choose to ship it in as long as it is licensed under the MPL.
I always saw the Freedom keyword as being about general user freedom, not strictly about the licensing. Furthermore, the Free Software Foundation considers that the definition of free software is explicitly about more than copyright licenses. Trademarks and patents are also to be considered for user freedom.
Replying to [comment:79 sgallagh]:
Replying to [comment:78 kkofler]: Various people have stated that the hardening features introduced in Firefox go against our principles. But nobody said specifically how. I did: It stops the user from exercising the Four Freedoms: http://www.gnu.org/philosophy/free-sw.html All 4 freedoms are impeded by the mechanism! Sorry, Kevin. I think this statement is overstated, but there's a worthwhile discussion to be had here. I'll go in order (and cite from that exact page): The freedom to run the program as you wish, for any purpose (freedom 0). "The freedom to run the program as you wish means that you are not forbidden or stopped from doing so. It has nothing to do with what functionality the program has, or whether it is useful for what you want to do." Freedom 0 specifically forbids clauses such as "for non-commercial use only" and the like. The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). The source code for Firefox is available. It can be recompiled by anyone who wants to do so. This Freedom does not and never has required that trademarks are preserved (that would be the province of the specific license chosen). The existence of !IceWeasel and !IceCat proves that this Freedom is retained for Firefox.
It rather proves the opposite. !IceCat was created because the GNU project and the Free Software Foundation consider Mozilla Firefox to be proprietary software (the privacy and security features were added later), and the Debian project has decided that Mozilla Firefox does not meet the Debian Free Software Guidelines. This in turn is why Iceweasel was created.
I would prefer the Iceweasel solution too.
Mozilla is trying to take away the rights of the user by not allowing unsigned extensions. Right now, the user can still run unsigned extensions, but that feature is apparently going away in firefox 44.
What I'm concerned with is who signs these extensions, and who is responsible for deciding what gets signed and what doesn't. What if I write an awesome extension, submit it for signing, and the signing group doesn't like what I write, and doesn't sign the extension. Since it's not signed, I can't load it.
What if this extension competes with something that Mozilla is already doing in Firefox? This is the other big problem, because these app stores decide what goes and what doesn't, and those stores will not let any app in if it competes with the store owners' apps - preventing competition.
I don't think this type of behavior violates any kind of licenses, but it sure isn't good behavior.
I still believe Stephen's proposal 2 is worth doing from a FESCo level.
However, as an alternative to his proposal 1, I would suggest the issue of whether or not to include Firefox 44 and beyond as-is be submitted to individual Working Groups. There is no reason FESCo should decide this for the entire distribution, as each Working Group is capable of determining how the signing issue impacts them. Similarly, there is no reason to remove Firefox as it is currently built from the entire distribution as there are users who will want to use it as it is provided from Firefox.
This cannot be handled at WG level because there needs to be a distro-wide upgrade path for those who have Fedora 22 or 23 installed.
Replying to [comment:88 kkofler]:
There already is a distro-wide upgrade path for people who have F22 or F23 installed. People with existing installs are using Firefox. When they update, they get Firefox. If they do not wish to use the version they are provided, they can install something else and we can help them do so.
The whole point of this thread is that Firefox 44 is '''not''' an acceptable upgrade path for Fedora users, and most definitely not for users of a stable release.
Ack! I'm really disappointed about this signing stuff, '''I''' want to decide which people I trust. Some kind of warning in case of unsigned addons is fine. But disabling them without any control for the user... (Will be case for FF 44 if I interpret correctly?). I trust Fedoras packagers and I like to use the packaged addons ;)
Replying to [comment:90 kkofler]:
Yes, you've suggested that. A number of others have disagreed.
One can imagine replacing Firefox with some other browser certainly violates the principle of least surprise and users will be rather confused. I don't believe that's a good option. Even if it were chosen, we would still have to help users understand exactly what happened with surrounding documentation as to what just happened and unilaterally making that choice for them is wrong.
The suggestion of locking Fedora into Firefox 43 isn't viable either.
Replying to [comment:91 lupinix]:
These interjections of "me too" aren't helping this discussion. Everyone is welcome to monitor it but it would be great if people limited participation to input that's new, insightful, or directly relevant to an open question.
Replying to [comment:87 jwboyer]:
Thanks. If people want to vote here in the ticket (or on Friday), I'd be happy to draft the missive.
As an added argument for it, I think that if we take any other action in Fedora without at least ''attempting'' to discuss this with upstream, we would be violating the spirit of the Friends foundation.
Replying to [comment:92 jwboyer]:
Replying to [comment:90 kkofler]: The whole point of this thread is that Firefox 44 is '''not''' an acceptable upgrade path for Fedora users, and most definitely not for users of a stable release. Yes, you've suggested that. A number of others have disagreed. One can imagine replacing Firefox with some other browser certainly violates the principle of least surprise and users will be rather confused. I don't believe that's a good option. Even if it were chosen, we would still have to help users understand exactly what happened with surrounding documentation as to what just happened and unilaterally making that choice for them is wrong. The suggestion of locking Fedora into Firefox 43 isn't viable either.
Yeah, the more I think about this, the less I like any answer that involves silently changing the user's browser without their consent (which includes switching to Firefox ESR, so I'm going to vote -1 on my own Proposal 1). That being said, I think there's value in highlighting the situation in a public forum, perhaps in the form of a Fedora Magazine article where we identify the contentious points and suggest some alternatives that our more cautious users can elect to install as well.
As for Josh's suggestion about leaving the default up to the WGs, I think that's pretty much already the case, so I don't think we need to actually vote on it. None of the Editions or Spins today are shipping with any packaged extension installed by default (so far as I can spot in spin-kickstarts, at least), so it's not going to directly impact the fresh install cases.
Replying to [comment:90 kkofler]: The whole point of this thread is that Firefox 44 is '''not''' an acceptable upgrade path for Fedora users, and most definitely not for users of a stable release. Yes, you've suggested that. A number of others have disagreed. One can imagine replacing Firefox with some other browser certainly violates the principle of least surprise and users will be rather confused.
One can imagine replacing Firefox with some other browser certainly violates the principle of least surprise and users will be rather confused.
We would not be replacing Firefox with "some other browser". It would be '''the same''' browser, just with another '''name'''. Rebranding a program for trademark reasons has been done in updates more than once, e.g., KTron to KSnakeDuel.
I don't believe that's a good option. Even if it were chosen, we would still have to help users understand exactly what happened with surrounding documentation as to what just happened and unilaterally making that choice for them is wrong.
It is unilaterally making the choice of breaking the users' extensions that is wrong. It is a blatant violation of the guidelines for updates to stable releases.
https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases
I realize that we have painted ourselves into a corner. I have warned about that all this time. The opponents of rebranding never wanted to listen. Now we suffer the results. I think pushing a rebranding to our stable releases as an update is clearly the lesser evil to get out of the impasse, and also avoids such a dilemma from occuring again in the future. We clearly need the freedom to modify the software we ship to comply with our policies, and the Mozilla trademark policy is in clear conflict with that.
The trademark guidelines don't even give us the option to backport security fixes to the version we ship, an option we '''need''', because that is exactly how the issue of incompatible updates is addressed for all other software.
Replying to [comment:94 sgallagh]:
The thing is that we urgently need something like a "preliminary injunction" to block upgrading to Firefox 44 until a decision is made. If Firefox 44 is pushed as is, the damage is done!
Yeah, the more I think about this, the less I like any answer that involves silently changing the user's browser without their consent
See above, we would not be '''changing''' their browser, only '''renaming''' it.
(which includes switching to Firefox ESR, so I'm going to vote -1 on my own Proposal 1).
This makes even less sense, Firefox ESR is closer to what the users are already running than the bleeding-edge Firefox that changes all the time in surprising ways.
That being said, I think there's value in highlighting the situation in a public forum, perhaps in the form of a Fedora Magazine article where we identify the contentious points and suggest some alternatives that our more cautious users can elect to install as well.
None of this addresses the issue that an update is going to be pushed really soon that replaces our default browser with something not acceptable for Fedora. It's still called Firefox, but it does not behave like the Firefox we shipped, and it no longer complies to the Free Software Definition.
As I have explained many times, this is not only about the packaged extensions, but also about '''the user''''s extensions!
The default applications regularly change from one release to another, though. The web browser is one of the most important applications, but when default applications change, it's usually from one application to a completely different one (while here we're talking about rebranding Firefox, not replacing it by something completely different). Furthermore in this case we have multiple really good reasons to change the browser (extension signing, nonfree software, being able to modify the browser in the future, etc.), while when default applications change it's typically just because the old application wasn't maintained, the new application provides better integration and so on. I don't think renaming the web browser is anything extraordinary, and I'm sure users will recognize Firefox as soon as they open it.
However, I agree that the situation should be highlighted in a public forum (Fedora Magazine article or otherwise), especially if the browser is rebranded.
What if nodejs introduced mandatory signing for all npm js packages and they could only be signed by publishing them to npmjs.com? What if python introduced mandatory signing for python modules and the only signed ones would be available from pypi.python.org? Nobody would think twice about patching nodejs or python interpreters to accept Fedora certificate if upstream didn't have an option for signed distribution-packaged modules. Why are we so afraid of renaming Firefox, then? Debian seems to be doing just fine with Iceweasel. I believe there were a couple of FESCo meetings in the meantime. Was this discussed by FESCo at all? Has anyone reached out to Mozilla yet? I believe the relevant arguments were made here already, so what are we waiting for?
As an end user, I find I'm really pretty ticked off about Mozilla's attitude here. In the long term I as an end user would like you to find and package a realistic alternative. I know that's hard. I know it may even be impossible. But it's what I'd like, because this isn't Mozilla's first display of bad attitudes.
Meanwhile, in the SHORT term, while you guys lawyer at each other about arcane internal Fedora policies, the bottom line remains that you are on the path to dropping functionality that I use and care about, that others plausibly use and care about, and that any reasonable person would expect would stick around. Could that be the priority, please?
I could live with a renamed Firefox. Nobody cares about the name, and frankly Mozilla needs to be woken up by as many slaps in the face of their "brand" as possible. I appreciate their efforts to provide what has historically been a good browser, but they've let too many well meaning idiots into the kitchen, and maybe enough shocks will motivate them to fix that.
I could live with the developer's edition. It wouldn't even have to be the default version if it were in the regular repos. But if you wanted to make it the default, that would be OK, too.
Just as long as you package a full featured, working Web browser that doesn't try to tell me what I can and can't do with my own computer, and doesn't start doing so the next time I type "dnf upgrade", I'm at least reasonably happy.
But I'd really, really like it if you packaged it. I've been using Linux (and Red Hat/Fedora) since 1996, but I've been happier since I stopped having to recompile half the programs in the distro. I don't want to go back to that.
jbash, do note that icecat is already included in the Fedora repositories.
We'll discuss this in the meeting tomorrow at 17:00 UTC on #fedora-meeting
Replying to [comment:99 jbash]:
In the long term I as an end user would like you to find and package a realistic alternative.
https://fedoraproject.org/wiki/Changes/QtWebEngine
https://copr.fedorainfracloud.org/coprs/kkofler/qtwebengine/
+1 for blocking Firefox 44 And +1 to sgallagh Proposal 2.
That's not the first time, they implemented a controversial feature from FOSS ecosystem PoV and forget to make it easily unconfigurable. Let's try working with them as we've had a good long-term partnership.
But if it does not get fixed, I would be in favour to switch over Iceweasel rather than shipping a modified Firefox and keep the branding. As a leading FOSS actor, we have to make our stance about such changes explicit.
im more in Favor of Mozilla keeping this option. for Linux Builds
'''Firefox retains the option to disable signature checking for extensions.'''
Mozilla has pushed out things a bit: https://blog.mozilla.org/addons/2016/01/22/add-on-signing-update/
it will now be firefox 46 that no longer can disable the signature check.
So it looks like an upgrade path is available for our existing releases that is not a downgrade nor a rename and at least retains the option to disable this nonsense: 43 → 44 → 45 ESR and stick to that.
I still think there is ultimately no way around rebranding and removing the signature check completely (and also the ads on the pages generated by the browser).
Replying to [comment:100 mattdm]:
Again, IceCat is something different. What people here seem to want is '''Iceweasel''', which is really just Debian's rebranded Firefox, closely tracking Mozilla upstream.
But maybe Mozilla wouldn't even be opposed to a patch that adds the capability to load additional trusted public keys from a root-owned directory? The security model for the signature enforcement appears to be designed with a specific environment and specific attack vectors in mind. Fedora is not that environment. It appears that Linux distributions weren't given much though in the design process. So maybe they're ok with adjusting the feature to better match our environment and security needs? Does anybody have a contact at Mozilla to get a dialog started? Martin? Just read the FESCo meeting minutes, sgallagh (thanks!) is going to write something.
This gives us until 2016-04-19, which is a huge temporary relief. I doubt we'll have reached a satisfactory agreement with Mozilla by then, but at least we'll have communication ongoing and will have had time to decide what to do for Firefox 46. Firefox ESR 45.0 will be released on 2016-03-08, so we would be able to switch to ESR (until we have a satisfactory solution, whether that is agreement with Mozilla or a rebranded or unbranded browser ready). Hopefully it can all be solved before the Fedora 44 release.
just get used to using Google Chrome.an or Chromium, thats my other solution, least it comes with an updated Flash. but what if Fedora just makes '''Seamonkey''' Default?
Gentle reminder: there will be no discussion about Fedora's default browser until we've sorted out this question with the Mozilla Foundation.
And in the case we consider to change the default browser, it needs to go through the usual changes process and in collaboration with the Workstation WG. This is just not the right for this discussion.
Replying to [comment:109 lseipel]:
Replying to [comment:100 mattdm]: jbash, do note that icecat is already included in the Fedora repositories. Again, IceCat is something different. What people here seem to want is '''Iceweasel''', which is really just Debian's rebranded Firefox, closely tracking Mozilla upstream.
Indeed, this confusion keeps appearing in this discussion.
Fedora provides packages for '''icecat''' - https://bodhi.fedoraproject.org/updates/?packages=icecat - https://en.wikipedia.org/wiki/GNU_IceCat
The Iceweasel name relates to the Debian maintained package, which AFAIK doesn't exist as an rpm package.
Mozilla has some points listed on the page about the signing which I don't think have been specifically covered here, and seem to match at least one of the above suggestions for solutions
Additional signing keys being supported option:
What about private add-ons used in enterprise environments? 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.
If Mozillla add support for private signing keys for the enterprise scenario, this should also work for Fedora with signing packaged addons.
Another thing I haven't seen any real discussion around, is to sign the Fedora packages hosted outside of AMO. The EFF do this with their HTTPS Everywhere and Privacy Badger addons, which I install from the EFF website and seem redundant IMO as Fedora packages.
How do I get my add-ons signed if they are not hosted on addons.mozilla.org (AMO)? You will need to create an AMO account and submit your add-on. There will be an option where you indicate the add-on won't be listed on AMO, and you'll be able to submit your add-on files without having them published on the site. Please read the Distribution Policy for more details. You can also use the jpm sign command to generate a signed XPI that can be self-hosted. There is an API you can use for signing. How does the signing process work for unlisted add-ons? For unlisted add-ons, files submitted for signing will go through an automated review process. If they pass this review, they are automatically signed and a download link is sent back to the developer. This process should normally take seconds. If the file doesn't pass review, the developer will have the option to request a manual review, which should take less than two days. This is not the same process that currently applies to AMO add-ons, which has been typically slower. There is an API you can use for signing.
'''Fedora Endgame'''
If Fedora goes ahead with renaming/rebranding Firefox to something like SnowLemon or FrozenHell, what proposal will users be given to download and remain using Firefox?
Will it need to be in a private repository? Will users need to wait for Mozilla to provide a repository? Will it be forced into RPMFusion non-free?
Icecat provides an example of 'maintain it ourselves'. While it is available and updated, it doesn't keep up with the release numbers that Firefox use. Even if fixes are backported, that's extra workload explaining to all the users why the version numbers are so different.
And while Fedora has made other browsers available like Chromium, there are still a lot of requests for information on installing Google Chrome. Because people like to use what they know, and they know the brand names, not Fedora principles or all the variations of defining 'freedom'.
People will see news about this ticket as "Fedora are removing Firefox", and that's enough reason for new users to install something else
Why not just use chrome? Chromium is open source...
@supercilex: this is not the right time to discuss that point.
I have read in this ticket as well as on the [https://lists.fedoraproject.org/archives/list/desktop%40lists.fedoraproject.org/thread/IVCNH55VM6UXEASJ6AWXNP6LVTWYEQC2/ Desktop List] multiple times, that having additional trust chains in Firefox would be a possible solution.
Sure, including a Fedora CA in Firefox for signing add-ons would allow Fedora to sign and ship Firefox add-on packages again.
But it would not solve:
being able to develop or debug Firefox add-ons in Fedora (according to https://wiki.mozilla.org/Add-ons/Extension_Signing#FAQ only the "Developer Edition", the "Nightly" versions or special "unbranded versions" will have the setting to disable signature enforcement)
having the freedom to install any add-on
Replying to [comment:114 ardrigh]:
Why would they want that? They'll effectively already remain using Firefox, it'll just not be '''called''' "Firefox" anymore. As far as I know, almost all Debian users are fine with Iceweasel.
If people really want a branded Firefox (I don't see why they would), it could be in any of those. But surely not in Fedora or RPM Fusion Free. Nor in Copr if it is ruled to not comply with Fedora freedom guidelines.
Icecat provides an example of 'maintain it ourselves'.
No, it is actually an example of "rely on an external upstream to maintain the rebranded version". The idea of the "Iceweasel solution" is to avoid exactly that.
While it is available and updated, it doesn't keep up with the release numbers that Firefox use.
That's why taking upstream Firefox, rebranding it with automated scripts, and applying easily-rebased patches, as Debian is doing, is the way.
No, the Chromium case is very particular: Chromium is not in official Fedora repositories yet either, Chrome offers some "value adds" (the FSF would rather call them freedom subtractions) that make some users want it: support for patent-encumbered codecs (the answer there is that we need GStreamer support so people can simply use the codecs from RPM Fusion), bundled proprietary plugins for Flash and DRM (Widevine). The rebranded Firefox would not have such differences.
Those are the reasons that make people want Chrome, not the name.
Debian is still as popular as ever, rebranding Firefox did not hurt them in any measurable way.
We discussed this in Friday's FESCo meeting and decided to discuss the issue with Mozilla and meanwhile keep on shipping latest Firefox releases in Fedora.
ACTION: sgallagh to draft a polite, private email to Mozilla expressing our concerns and several potential mitigation approaches. This will be done before the next FESCo meeting. (sgallagh, 17:28:13)
AGREED: For the time being, we continue to permit Fedora to update to the latest upstream release of Firefox while we negotiate with their upstream. (+1:8, 0:0, -1:0) (kalev, 17:44:02)
https://meetbot.fedoraproject.org/fedora-meeting/2016-01-22/fesco.2016-01-22-17.02.html
In today's FESCo meeting, we agreed to remove the 'meeting' keyword form this ticket and re-visit in the future, as necessary.
I opened the conversation with Mozilla on this last week. They responded saying that they would give us a detailed reply soon and thanking us for enumerating the issues we see with this situation. They have not yet replied with this detailed response, so I pinged them again. I'm not putting this on the agenda for this week.
Some suggested Iceweasel as a solution, but looks like Firefox is coming back to Debian and their maintainers will discontinue Iceweasel as an re-branded version of Firefox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
Seems like Debian which is usually very puritan in this matter don't find anything unacceptable about Firefox after Mozilla solved the copyright licensing issue.
/me just thought it could be relevant to this discussion.
Replying to [comment:123 eischmann]:
We should probably come up with our own rebranded name anyway. I don't see how this affects us in any way.
It shows they learned nothing from the past and are headed towards new trouble once Mozilla's stance changes yet again. There is still no trademark license nor any other kind of legally binding arrangement that would prevent something like the previous conflict from resurfacing (where Mozilla had suddenly announced that the prior informal understanding that the patches are acceptable was no longer valid because the people responsible had changed). I do not understand how, after that past experience, they are suddenly happy with another unsafe informal arrangement of the same kind. (The most likely explanation is a conflict of interest, considering that the 2 people who pushed for this are Mozilla employees. I see the same kind of conflicts of interest in Fedora.)
Not all that much, because we are not Debian.
Martin, please apply https://sources.debian.net/patches/iceweasel/45.0~b5-1/debian-hacks/Allow-unsigned-addons-in-usr-lib-share-mozilla-exten.patch/ to Fedora's Firefox package. We're still awaiting the formal document from Mozilla stating that this is acceptable, but I've been told through a back-channel that we should just go ahead and run with it.
To anyone reading this thread, this patch disables signature verification for any add-on that is installed to /usr/lib and is viewed by FESCo as satisfying our requirements at this time.
Replying to [comment:127 sgallagh]:
Well and the back-channel is? I'd like to have more assurance here before we ship iceweasel patch which breaks major Firefox feature. Does Debian ship this patch in its official branded browser?
Replying to [comment:128 stransky]:
Does Debian ship this patch in its official branded browser?
Yes — verify here: https://sources.debian.net/patches/firefox/46.0~b1-1/
The Debian patch is no solution to the problem, as I pointed out in the Fedora bug for it: https://bugzilla.redhat.com/show_bug.cgi?id=1293874#c5
It only addresses one special case of the issue.
Replying to [comment:129 mattdm]:
Replying to [comment:128 stransky]: Does Debian ship this patch in its official branded browser? Yes — verify here: https://sources.debian.net/patches/firefox/46.0~b1-1/
Fair enough, I'll update our package then.
firefox-45.0.1-2 carries such patch.
As kkofler says, disabling the signature check on "system" extensions is NOT a fix for the problem that actual users face here. It's not even close.
I don't want to have to install every extension for every user. Sometimes users want different things on shared computers. I also don't want to pollute my system directories with files that aren't in packages. That makes it hard to maintain a clean system and do upgrades. At the same time, I don't want to create an RPM for every Firefox extension I install. That's a pain in the butt.
I want to install unsigned extensions, and/or extensions signed by '''me''', ''as a regular user'', ''in my user account''. Loss of that longstanding functionality would be a significant inconvenience.
On the other hand, I would not be inconvenienced in the slightest by using a browser renamed "Iceweasel", "Waterotter", or whatever you want to call it. So I'm not prepared to ''accept'' the inconvenience for the privilege of calling it "Firefox". Mozilla can go ahead and do whatever it wants to Mozilla's brand, but that brand is of no concern to me.
Replying to [comment:133 jbash]:
There's no impediment to having such a browser in Fedora in addition to the Firefox-branded build. In fact, we already have one example in IceCat.
Replying to [comment:134 mattdm]:
Yes. The problem here is that some people demand such unbranded browser but no one is willing do the real work, create the package and maintain it in Fedora.
The package would lose a lot of value without Obsoletes / Provides: firefox. And having both would also not solve the problem that Firefox does not comply with the Free Software definition and thus should not be allowed in Fedora.
Note that signature enforcement has been pushed back again, now to Firefox 48....
Alright, so the patch applied from comment 127 is an improvement, allowing root to install addons for all users in /usr/{lib,share}/mozilla/extensions
However, there are still users who would prefer, for various reasons, to either disable the signature checking entirely, or to add their own trusted keys ... it would seem that either or both of these options are possible, given the patch from comment 127, if someone writes a Firefox extension that does this (it wouldn't have to be signed), and then a package could be provided to install that extension to /usr/{lib,share}/mozilla/extensions , allowing all users, once installed, to administer their own extensions without needing access to /usr/{lib,share}/mozilla/extensions
Any volunteers for creating such extension, and/or maintaining a package for it?
Login to comment on this ticket.