[arch-general] Firefox without signature checking
Hello, Are there plans to package a version of Firefox 44 that lets you disable extension signature checking? Background: Firefox is shipping with signature checking for addons. Right now (in Firefox 43), there is an option to disable it if you need to use an unsigned addon. However, that option is being removed in Firefox 44. [0] Signature checking itself is actually a very good concept. However, the way Mozilla has implemented it in Firefox (imho) is not. Every extension must be signed by Mozilla, and only Mozilla, creating a walled garden. From my understanding, there will be no way to override this extension check unless you recompile Firefox and build an unbranded version. Personally, I think this mechanism goes against the Arch Linux tenet of user centrality [1]. As a user, you should ultimately be allowed to decide what you want to install on your system. Also, how are you supposed to build your own extensions or test someone else's extension on Firefox stable? Fedora recently discussed the possibility of packaging an "unofficial" Firefox [2]. (Take a look at their bugtracker for some good points.) Is an abrowser package with the ability to disable extension signing warranted? I am posting to this mailing list because I have not seen much discussion about Firefox extension signing in the Arch Linux world. Developers, what are your thoughts? Is it worth it packaging an "unofficial" version of Firefox? --Kyle Terrien [0] https://wiki.mozilla.org/Addons/Extension_Signing [1] https://wiki.archlinux.org/index.php/Arch_Linux#User_centrality [2] https://fedorahosted.org/fesco/ticket/1518
On 2 January 2016 at 20:17, Kyle Terrien <kyleterrien@gmail.com> wrote:
Hello,
Are there plans to package a version of Firefox 44 that lets you disable extension signature checking?
Background: Firefox is shipping with signature checking for addons. Right now (in Firefox 43), there is an option to disable it if you need to use an unsigned addon. However, that option is being removed in Firefox 44. [0]
Signature checking itself is actually a very good concept. However, the way Mozilla has implemented it in Firefox (imho) is not. Every extension must be signed by Mozilla, and only Mozilla, creating a walled garden. From my understanding, there will be no way to override this extension check unless you recompile Firefox and build an unbranded version.
Personally, I think this mechanism goes against the Arch Linux tenet of user centrality [1]. As a user, you should ultimately be allowed to decide what you want to install on your system. Also, how are you supposed to build your own extensions or test someone else's extension on Firefox stable? Fedora recently discussed the possibility of packaging an "unofficial" Firefox [2]. (Take a look at their bugtracker for some good points.)
Is an abrowser package with the ability to disable extension signing warranted?
I am posting to this mailing list because I have not seen much discussion about Firefox extension signing in the Arch Linux world. Developers, what are your thoughts? Is it worth it packaging an "unofficial" version of Firefox?
--Kyle Terrien
This sounds like something for the AUR. I do not agree with this move from Mozilla and it would be interesting to see the interest in such a package.
On 01/02/2016 03:32 PM, Ben Oliver wrote:
On 2 January 2016 at 20:17, Kyle Terrien <kyleterrien@gmail.com> wrote:
This sounds like something for the AUR. I do not agree with this move from Mozilla and it would be interesting to see the interest in such a package.
Agree - AUR. Arch should follow upstream - if there is a spin off alternative with this disenagaged (HigherFox or whatever) ... we can certainly choose a different package - but Arch should stick with the upstream version. Aside: I don't use firefox - but curious - how would one test developer versions of extensions then? Or is this no longer possible in firefox?
This sounds like something for the AUR. I do not agree with this move from Mozilla and it would be interesting to see the interest in such a package.
Agree - AUR.
Arch should follow upstream - if there is a spin off alternative with this disenagaged (HigherFox or whatever) ... we can certainly choose a different package - but Arch should stick with the upstream version.
Aside: I don't use firefox - but curious - how would one test developer versions of extensions then? Or is this no longer possible in firefox?
There will be support for that of course https://developer.mozilla.org/en-US/Add-ons/Distribution -- damjan
On 01/02/2016 12:47 PM, Damjan Georgievski wrote:
Aside: I don't use firefox - but curious - how would one test developer versions of extensions then? Or is this no longer possible in firefox?
There will be support for that of course https://developer.mozilla.org/en-US/Add-ons/Distribution
It looks like that is only intended for release-status extensions. If I want to QA test a developer's beta build, this tells me that the developer would have to submit each build he wishes me to test to AMO. Why can't I just package the extension myself and load it? That is absurd. --Kyle Terrien
Am 02.01.2016 um 22:52 schrieb Kyle Terrien:
It looks like that is only intended for release-status extensions. If I want to QA test a developer's beta build, this tells me that the developer would have to submit each build he wishes me to test to AMO. Why can't I just package the extension myself and load it? That is absurd. --Kyle Terrien
The official stance is that developers and testers should use the "Developer Version"[1] of Firefox. That release does not require extension signatures. [2] Jan Steffens (heftig) provides us with a compiled Arch Linux package in his repository. [3][4] You can always provide or request an unofficial repository with binary packages of other firefox based projects. 1: https://www.mozilla.org/firefox/developer/ 2: https://wiki.mozilla.org/Add-ons/Extension_Signing 3: https://bbs.archlinux.org/viewtopic.php?id=117157 4: http://pkgbuild.com/~heftig/repo/ -- Andreas Bosch
On 01/02/2016 02:42 PM, ProgAndy wrote:
Am 02.01.2016 um 22:52 schrieb Kyle Terrien:
It looks like that is only intended for release-status extensions. If I want to QA test a developer's beta build, this tells me that the developer would have to submit each build he wishes me to test to AMO. Why can't I just package the extension myself and load it? That is absurd. --Kyle Terrien
The official stance is that developers and testers should use the "Developer Version"[1] of Firefox. That release does not require extension signatures. [2] Jan Steffens (heftig) provides us with a compiled Arch Linux package in his repository. [3][4]
You can always provide or request an unofficial repository with binary packages of other firefox based projects.
1: https://www.mozilla.org/firefox/developer/ 2: https://wiki.mozilla.org/Add-ons/Extension_Signing 3: https://bbs.archlinux.org/viewtopic.php?id=117157 4: http://pkgbuild.com/~heftig/repo/
Cool! It's nice to know someone has my back when it comes to the Developer Addition. But what about regression testing? (Testing against older "supported" versions, or in this case the "stable" version of Firefox) So far, the only way it looks like is to either download the unofficial build from Mozilla or build Firefox yourself. --Kyle Terrien
On 01/02/2016 05:12 PM, Kyle Terrien wrote:
You can always provide or request an unofficial repository with binary packages of other firefox based projects.
1:https://www.mozilla.org/firefox/developer/ 2:https://wiki.mozilla.org/Add-ons/Extension_Signing 3:https://bbs.archlinux.org/viewtopic.php?id=117157 4:http://pkgbuild.com/~heftig/repo/
Cool! It's nice to know someone has my back when it comes to the Developer Addition.
But what about regression testing? (Testing against older "supported" versions, or in this case the "stable" version of Firefox) So far, the only way it looks like is to either download the unofficial build from Mozilla or build Firefox yourself.
Yes, good bunch those archers... For testing against the stable version, the stable or ESR branch of firefox. (currently at 38.5.2) is at [1]. It is a drop in that works fine in /opt. 1. https://ftp.mozilla.org/pub/firefox/releases/38.5.2esr/ -- David C. Rankin, J.D.,P.E.
This sounds like something for the AUR. I do not agree with this move from Mozilla and it would be interesting to see the interest in such a package.
If that is Mozilla's plan, I will most definitely use or make an alternative package. I use Pentadactyl, which is currently unsigned, and I will not switch away from it anytime soon. I agree that an alternative package would probably belong in the AUR, at least for starters.
On Sat, Jan 02, 2016 at 09:01:10PM +0000, Emil Lundberg wrote:
If that is Mozilla's plan, I will most definitely use or make an alternative package. I use Pentadactyl, which is currently unsigned, and I will not switch away from it anytime soon. I agree that an alternative package would probably belong in the AUR, at least for starters.
As to the future of Pentadactyl: https://github.com/5digits/dactyl/issues/99
On Sat, 2 Jan 2016 12:17:52 -0800 Kyle Terrien <kyleterrien@gmail.com> wrote:
Hello,
Are there plans to package a version of Firefox 44 that lets you disable extension signature checking? ... --Kyle Terrien
On 01/02/2016 01:23 PM, Doug Newgard wrote:
On Sat, 2 Jan 2016 12:17:52 -0800 Kyle Terrien <kyleterrien@gmail.com> wrote:
Hello,
Are there plans to package a version of Firefox 44 that lets you disable extension signature checking? ... --Kyle Terrien
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted. It looks like sticking to upstream trumps user-centric in this case. (Although I guess building from AUR is a fair substitute for user-centric.) It's a real bummer that a bunch of users (myself included) will be forced to compile Firefox on each release. I really hope we can eventually get an abrowser or firefox-nobranding (or maybe even palemoon) into the repos. How can we nominate a package into community or extra? (And if you are fed-up with Mozilla's walled-garden policy like I am, I suggest trying out Pale Moon [0].) --Kyle Terrien [0] https://www.palemoon.org/
On 16/01/02 14:06, Kyle Terrien wrote:
On 01/02/2016 01:23 PM, Doug Newgard wrote:
On Sat, 2 Jan 2016 12:17:52 -0800 Kyle Terrien <kyleterrien@gmail.com> wrote:
Hello,
Are there plans to package a version of Firefox 44 that lets you disable extension signature checking? ... --Kyle Terrien
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
It looks like sticking to upstream trumps user-centric in this case. (Although I guess building from AUR is a fair substitute for user-centric.)
It's a real bummer that a bunch of users (myself included) will be forced to compile Firefox on each release. I really hope we can eventually get an abrowser or firefox-nobranding (or maybe even palemoon) into the repos.
What about an AUR-package with a pre-compiled binary? Sure I have to trust the maintainer. But I also have to with a source-package since I won't check the sources with each release ;) Niels
On Sat, Jan 02, 2016 at 11:25:12PM +0100, Niels Kobschaetzki wrote:
What about an AUR-package with a pre-compiled binary? Sure I have to trust the maintainer.
No, this is a recipe for spreading malware. Also, have you seen the size of said binary?
But I also have to with a source-package since I won't check the sources with each release ;)
Which is plain stupid. Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Leonid Isaev writes:
On Sat, Jan 02, 2016 at 11:25:12PM +0100, Niels Kobschaetzki wrote: [..]
But I also have to with a source-package since I won't check the sources with each release ;)
Which is plain stupid.
How is that stupid? Do you check the sources with each release? *How* do you perform those checks? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- R.P. Feynman
But I also have to with a source-package since I won't check the sources with each release ;)
Which is plain stupid.
How is that stupid? Do you check the sources with each release? *How* do you perform those checks?
Perhaps there's a misunderstanding here. Not checking at least the PKGBUILD on each rebuild *would* be reckless at best and plain stupid at worst, but that's not what you suggested. Assuming trust in the upstream, I don't see too big an issue with simply asserting that the PKGBUILD pulls the source from the right place over an authenticated channel (i.e. HTTPS) and doesn't do anything weird in the build functions.
On Sun, Jan 03, 2016 at 12:18:36AM +0100, Magnus Therning wrote:
How is that stupid? Do you check the sources with each release? *How* do you perform those checks?
OK, fact #0 - I only use software whose upstream I trust. Having said that, I usually pull md5sums and sha*sums in the PKGBUILD, all from different sources (upstream, Debian, Gentoo, etc.), if the src is not upstream-signed. FF releases _are_ signed (I don't know why the PKGBUILD in [extra] doesn't check that), so just have the Mozilla signing key (currently 0x61B7B526D98F0353) in your keychain. If you trust random people in the AUR and never inspect their PKGUILDs, or even worse, use their binaries, you deserve to be rooted. Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Leonid Isaev writes:
On Sun, Jan 03, 2016 at 12:18:36AM +0100, Magnus Therning wrote:
How is that stupid? Do you check the sources with each release? *How* do you perform those checks?
OK, fact #0 - I only use software whose upstream I trust.
How do you establish that trust?
Having said that, I usually pull md5sums and sha*sums in the PKGBUILD, all from different sources (upstream, Debian, Gentoo, etc.), if the src is not upstream-signed. FF releases _are_ signed (I don't know why the PKGBUILD in [extra] doesn't check that), so just have the Mozilla signing key (currently 0x61B7B526D98F0353) in your keychain.
If you trust random people in the AUR and never inspect their PKGUILDs, or even worse, use their binaries, you deserve to be rooted.
Ah, you mean you check the origins of the source code, not the source code itself. My bad. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
It looks like sticking to upstream trumps user-centric in this case. (Although I guess building from AUR is a fair substitute for user-centric.)
Yes, that's what the SVN repo is for: if you don't like the official release (= the one in binary repos), just clone && rebuild the thing yourself. As a bonus, you can get rid of unnecessary deps.
It's a real bummer that a bunch of users (myself included) will be forced to compile Firefox on each release. I really hope we can eventually get an abrowser or firefox-nobranding (or maybe even palemoon) into the repos.
Compiling FF doesn't take long if you disable PGO in PKGBUILD.
How can we nominate a package into community or extra?
The package will have to get enough votes in the AUR and someone should want to maintain it in the repo.
(And if you are fed-up with Mozilla's walled-garden policy like I am, I suggest trying out Pale Moon [0].)
... which you need to build yourself anyway. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
And that request would be denied unless you can bring new info to the table. So far, I haven't seen any.
On Sat, Jan 02, 2016 at 04:50:06PM -0600, Doug Newgard wrote:
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
And that request would be denied unless you can bring new info to the table. So far, I haven't seen any.
Me? I fully support closing that bugreport. And moreover, I am not affected by the discussed issue, as I run FF beta... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2 Jan 2016 16:05:52 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 04:50:06PM -0600, Doug Newgard wrote:
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
And that request would be denied unless you can bring new info to the table. So far, I haven't seen any.
Me? I fully support closing that bugreport. And moreover, I am not affected by the discussed issue, as I run FF beta...
Cheers,
Just expanding on your point.
On Sat, Jan 02, 2016 at 05:34:51PM -0600, Doug Newgard wrote:
Just expanding on your point.
Ah, OK, sorry :) Also, perhaps one should note that "walled garden" discussions (albeit justified) belong at Mozilla's bug tracker, not Arch's. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Leonid Isaev writes:
On Sat, Jan 02, 2016 at 05:34:51PM -0600, Doug Newgard wrote:
Just expanding on your point.
Ah, OK, sorry :)
Also, perhaps one should note that "walled garden" discussions (albeit justified) belong at Mozilla's bug tracker, not Arch's.
Yes, and no. It should absolutely be brought up there first, but if Mozilla refuses to budge then it should be discussed here. It would be silly to *not* take advantage of the freedoms FLOSS gives us if upstream is deemed to be heading in the wrong way. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Finagle's Fourth Law: Once a job is fouled up, anything done to improve it only makes it worse.
Le 03/01/2016 02:27, Magnus Therning a écrit :
Leonid Isaev writes:
On Sat, Jan 02, 2016 at 05:34:51PM -0600, Doug Newgard wrote:
Just expanding on your point. Ah, OK, sorry :)
Also, perhaps one should note that "walled garden" discussions (albeit justified) belong at Mozilla's bug tracker, not Arch's. Yes, and no. It should absolutely be brought up there first, but if Mozilla refuses to budge then it should be discussed here. It would be silly to *not* take advantage of the freedoms FLOSS gives us if upstream is deemed to be heading in the wrong way.
/M
Of course, but then I think the appropriate use of our freedom is forking (even if it’s just to remove that function and maintain a patch that does so¹), else we’re moving far away of the official package (given this will require to disable branding or patch a lot, we couldn’t even name it Firefox anymore I think). Bruno ¹: If you look at Iceweasel they are mostly maintaining patches removing unwanted functions from Firefox, and add new patches for the same reasons from time to time, but still pull from Firefox. By the way, they might remove that function since it limits user freedom. Maybe you could ask them about that and go Iceweasel if Firefox does not suits your needs anymore. ;)
On 01/02/2016 02:50 PM, Doug Newgard wrote:
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
And that request would be denied unless you can bring new info to the table. So far, I haven't seen any.
The new info I have is that Mozilla is creating a walled garden. There is no way to override it besides rebuilding Firefox. The Fedora bugreport I pointed at earlier [0] compares this to package signing in RPM (or in our case pacman). The difference with package signing is that a user can add his own key and use that key to sign packages. In Firefox 44, you can do no such thing. You are at Mozilla's mercy. And Mozilla's add-on checker isn't perfect either [1]. These two reasons are why I believe that Mozilla's signature policy is a step in the wrong direction. On the other hand, I fully understand why we would want to follow upstream--less work for packaging and testing, as well as official sanctioning via branding. But I'm not affected much anyway because I'm on Pale Moon (using their official builds). --Kyle Terrien [0] https://fedorahosted.org/fesco/ticket/1518 [1] http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-the...
On Sat, 2 Jan 2016 15:26:59 -0800 Kyle Terrien <kyleterrien@gmail.com> wrote:
On 01/02/2016 02:50 PM, Doug Newgard wrote:
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
And that request would be denied unless you can bring new info to the table. So far, I haven't seen any.
The new info I have is that Mozilla is creating a walled garden. There is no way to override it besides rebuilding Firefox.
That's not new info, that's the same argument that was already rejected.
Doug Newgard writes:
On Sat, 2 Jan 2016 15:26:59 -0800 Kyle Terrien <kyleterrien@gmail.com> wrote:
On 01/02/2016 02:50 PM, Doug Newgard wrote:
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted.
You can only request to reopen...
And that request would be denied unless you can bring new info to the table. So far, I haven't seen any.
The new info I have is that Mozilla is creating a walled garden. There is no way to override it besides rebuilding Firefox.
That's not new info, that's the same argument that was already rejected.
The issue in question ([1]) was raised before release 43, where signature checking, AFAIU was turned on by default but could be manually disabled. The new info would be that for release 44, signature checking would not only be turned on by default but there would be no way to disable it. Do not confuse "no new info" with "there is new info, but that doesn't change our decision." The larger, and very philosophical question is "How user un-friendly can upstream make it before Arch decides to *not* package as upstream intends?" (Answering this requires keeping in mind that Arch users are unlikely to fall squarely into the target group of upstream.) /M [1]: https://bugs.archlinux.org/task/45900 -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Unix is the answer, but only if you phrase the question very carefully. -- Unknown
On 01/02/2016 07:24 PM, Magnus Therning wrote:
The larger, and very philosophical question is "How user un-friendly can upstream make it before Arch decides to *not* package as upstream intends?" (Answering this requires keeping in mind that Arch users are unlikely to fall squarely into the target group of upstream.) /M [1]: https://bugs.archlinux.org/task/45900 -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Unix is the answer, but only if you phrase the question very carefully. -- Unknown
I don't think Arch should even attempt to interperet questions like this. There is a very natural line that is easy to follow and solves all these issues. Upstream. It's simple, clear, and leaves no room for interpertation or future inconsistencies across different software packages. Release upstream as is (for the most part). If the user doesn't like a decision upstream has made; Compile it yourself, or change software. I don't entirely understand where Arch's responsibility lies in all of this to make a feature that is no longer standard in the developer's mind a part of the standard package. Arch shouldn't be answering philosophical questions. Just package it as is. I think it is VERY safe to say that people using unsigned stuff are in the minority, even for Arch users. On top of that, given Mozilla's recent history, this entire setup will probably change in 12 months making all of this moot. I think in the end, you need to ask yourself. When you install Firefox, do you want Firefox, or Arch's version of Firefox that has changes? I'm just a user. I'm a software developer, but not for Arch. As a user who recently switched to Arch, I did so to get the latest releases as they were released by upstream and just as important, *AS* they were released by upstream. -- Sajan Parikh 563.447.0995 sajan@parikh.io
Le 03/01/2016 02:24, Magnus Therning a écrit :
Doug Newgard writes:
On Sat, 2 Jan 2016 15:26:59 -0800 Kyle Terrien <kyleterrien@gmail.com> wrote:
On 01/02/2016 02:50 PM, Doug Newgard wrote:
On Sat, 2 Jan 2016 15:35:01 -0700 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote:
Thank you! I was tempted to reopen it, but it looks like the general consensus is that an AUR package will be submitted. You can only request to reopen... And that request would be denied unless you can bring new info to the table. So far, I haven't seen any. The new info I have is that Mozilla is creating a walled garden. There is no way to override it besides rebuilding Firefox. That's not new info, that's the same argument that was already rejected. The issue in question ([1]) was raised before release 43, where signature checking, AFAIU was turned on by default but could be manually disabled.
The new info would be that for release 44, signature checking would not only be turned on by default but there would be no way to disable it.
Do not confuse "no new info" with "there is new info, but that doesn't change our decision."
The larger, and very philosophical question is "How user un-friendly can upstream make it before Arch decides to *not* package as upstream intends?" (Answering this requires keeping in mind that Arch users are unlikely to fall squarely into the target group of upstream.)
/M
Sorry but you missed something: even if it was indeed prior to 43, this is still no new info. Because if you read the bug carefully, you will see this line: “ - Firefox 42: Release and Beta versions of Firefox will not allow unsigned extensions to be installed, with no override.” So the fact is just that as ever with Mozilla since the beginning of Firefox, it has been pushed two releases later. But overall, it’s still the same. ;) Bruno
Bruno Pagani writes:
Le 03/01/2016 02:24, Magnus Therning a écrit : [..] Sorry but you missed something: even if it was indeed prior to 43, this is still no new info. Because if you read the bug carefully, you will see this line:
“ - Firefox 42: Release and Beta versions of Firefox will not allow unsigned extensions to be installed, with no override.”
So the fact is just that as ever with Mozilla since the beginning of Firefox, it has been pushed two releases later. But overall, it’s still the same. ;)
Ah, thanks for pointing that out! /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Java is, in many ways, C++--. -- M Feldman
On 01/02/2016 05:24 PM, Magnus Therning wrote:
The larger, and very philosophical question is "How user un-friendly can upstream make it before Arch decides to *not* package as upstream intends?" (Answering this requires keeping in mind that Arch users are unlikely to fall squarely into the target group of upstream.)
This is a very good question to ask imho. In a perfect world, we would just fork and be done with it. However, it is not a perfect world. Forking requires time and effort, and it generally kills the software. (Here I am with several installs that have both Firefox and Pale Moon for compatibility reasons.) Most Arch users definitely do not fall into Mozilla's target group (an imaginary "average Joe" as I like to call it). We made this decision when we decided to install Arch as opposed to Ubuntu, Mint, OpenSUSE, or any other distro that does a decent job of configuring itself automatically. In 2015, we have seen a surprisingly large push for user un-friendliness in general. Firefox proposing add-on signing and removing features such as "complete" themes were just a couple examples. The GNOME folks are talking about breaking GTK themes again. I have lost track of how many "statically linked" QT libraries (e.g. bundled with Dropbox) that are completely broken. And in the world of other OSes, the Windows 10 release basically added spyware at the OS level to millions of users' PCs. So, the real question is where do you draw the line when something is un-friendly? And what do you do when the line is crossed? --Kyle Terrien
On 2016-01-03 06:11, Kyle Terrien wrote:
On 01/02/2016 05:24 PM, Magnus Therning wrote:
The larger, and very philosophical question is "How user un-friendly can upstream make it before Arch decides to *not* package as upstream intends?" (Answering this requires keeping in mind that Arch users are unlikely to fall squarely into the target group of upstream.)
This is a very good question to ask imho. In a perfect world, we would just fork and be done with it. However, it is not a perfect world. Forking requires time and effort, and it generally kills the software. (Here I am with several installs that have both Firefox and Pale Moon for compatibility reasons.)
What is wrong with e.g. IceWeasel, IceCat, Abrowser? And in which regard does forking "kill the software"? Especially if it only means applying certain patches upon each update of the original project? I totally agree with the decision of Arch's developers. If we stick with Firefox as provided upstream, this simplifies much: - Less work for the Arch developers - The features are exactly as expected, i.e. there is no Arch Firefox. - If the users dislike upstreams decisions, they will use a possibly newly created fork instead. If that achieves a sufficiently big user base, it will most likely be taken into the official Arch repositories. This has the side effect of making the original less popular and thereby making them think about their decision.
Most Arch users definitely do not fall into Mozilla's target group (an imaginary "average Joe" as I like to call it). We made this decision when we decided to install Arch as opposed to Ubuntu, Mint, OpenSUSE, or any other distro that does a decent job of configuring itself automatically.
In my opinon, it is actually very simple: If somebody does not fall into Mozilla's target group, he either - does not use it or - accepts that Mozilla does not care about his needs. When one decides to install Arch, one does also decide to get software as provided by upstream, patched as little as possible.
On Sat, Jan 02, 2016 at 03:26:59PM -0800, Kyle Terrien wrote:
On the other hand, I fully understand why we would want to follow upstream--less work for packaging and testing, as well as official sanctioning via branding.
It's neither. Mozilla advertises certain level of default security. If Arch is to reduce that, I think the package will need to be renamed, just not to mislead unsuspecting users. The expressed concerns have nothing to do with the branding or maintenance. Also, if you have specific concerns about the signing procedure, deal with people @Mozilla. (I don't really care because I don't use any addons.) Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (15)
-
Ben Oliver
-
Bruno Pagani
-
Damjan Georgievski
-
David C. Rankin
-
Doug Newgard
-
Dutch Ingraham
-
Emil Lundberg
-
Genes Lists
-
Kyle Terrien
-
Leonid Isaev
-
Magnus Therning
-
Niels Kobschaetzki
-
ProgAndy
-
respiranto
-
Sajan Parikh