I'm sure those that need to know, know, but for those that haven't heard[1] Mozilla's official Firefox build will enforce addons to contain a Mozilla signature without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
[1] https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experienc...
On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth mike@cchtml.com wrote:
I'm sure those that need to know, know, but for those that haven't heard[1] Mozilla's official Firefox build will enforce addons to contain a Mozilla signature without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
If the only way is to completely disable this feature, I'd prefer we don't. I wouldn't like for us to ship a less secure build of Firefox.
On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos comzeradd@fedoraproject.org wrote:
On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth mike@cchtml.com wrote:
I'm sure those that need to know, know, but for those that haven't heard[1] Mozilla's official Firefox build will enforce addons to contain a Mozilla signature without any runtime option to disable the check. Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla signing process takes time and can't be part of a package building process. Is Fedora going to get authorization to build Firefox with a runtime disable option?
If the only way is to completely disable this feature, I'd prefer we don't. I wouldn't like for us to ship a less secure build of Firefox.
A better way would be to add a "Fedora Signature" in addition to mozilla's and use that for packaged extensions. But that would require work on the build system (koji) side.
On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos comzeradd@fedoraproject.org wrote:
On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth mike@cchtml.com wrote:
I'm sure those that need to know, know, but for those that haven't heard[1] Mozilla's official Firefox build will enforce addons to contain a Mozilla signature without any runtime option to disable the check. Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla signing process takes time and can't be part of a package building process. Is Fedora going to get authorization to build Firefox with a runtime disable option?
If the only way is to completely disable this feature, I'd prefer we don't. I wouldn't like for us to ship a less secure build of Firefox.
A better way would be to add a "Fedora Signature" in addition to mozilla's and use that for packaged extensions. But that would require work on the build system (koji) side.
The RPMs deploying the packaged extension are already signed and those signatures are checked at time of package install. So it seems like firefox merely needs to be taught that the pre-packaged extensions deployed by RPM are pre-verified, so it can skip its verification for those, while still doing verification for stuff that is live downloaded
Regards, Daniel
On Thu, Feb 12, 2015 at 1:53 PM, Daniel P. Berrange berrange@redhat.com wrote:
On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos comzeradd@fedoraproject.org wrote:
On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth mike@cchtml.com wrote:
I'm sure those that need to know, know, but for those that haven't heard[1] Mozilla's official Firefox build will enforce addons to contain a Mozilla signature without any runtime option to disable the check. Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla signing process takes time and can't be part of a package building process. Is Fedora going to get authorization to build Firefox with a runtime disable option?
If the only way is to completely disable this feature, I'd prefer we don't. I wouldn't like for us to ship a less secure build of Firefox.
A better way would be to add a "Fedora Signature" in addition to mozilla's and use that for packaged extensions. But that would require work on the build system (koji) side.
The RPMs deploying the packaged extension are already signed and those signatures are checked at time of package install. So it seems like firefox merely needs to be taught that the pre-packaged extensions deployed by RPM are pre-verified, so it can skip its verification for those, while still doing verification for stuff that is live downloaded
Oh indeed. It is probably sufficient to just check the signature of non system wide extensions.
On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
A better way would be to add a "Fedora Signature" in addition to mozilla's and use that for packaged extensions. But that would require work on the build system (koji) side.
The RPMs deploying the packaged extension are already signed and those signatures are checked at time of package install. So it seems like firefox merely needs to be taught that the pre-packaged extensions deployed by RPM are pre-verified, so it can skip its verification for those, while still doing verification for stuff that is live downloaded
Yes, that does seem like the most practical way and reasonably secure way to handle this; it might make Mozilla unhappy anyway.
Firefox is really doing this to fight malware that has probably actually received (possibly unintended) permission from the user to install itself into the system, which often includes getting Administrator rights. So, to mirror that Mozilla intent exactly, even RPM-deployed extensions should require a Mozilla signature.
OTOH, once you give malware root rights, it can in principle modify Firefox to skip the check, so this is only a hurdle, not a reliable feature. Equally, verifying the RPM extension contents against the RPM database and checking the RPM signature would be useless because the malware can just add its key to the keys RPM uses for verification.
The Mozilla blog also mentions some “third option” for “extensions that will never be publicly distributed and will never leave an internal network”, presumably bypassing the need to have them signed by Mozilla. Could that be used by Fedora? Mirek
On Thu, 2015-02-12 at 09:16 -0500, Miloslav Trmač wrote:
On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
A better way would be to add a "Fedora Signature" in addition to mozilla's and use that for packaged extensions. But that would require work on the build system (koji) side.
The RPMs deploying the packaged extension are already signed and those signatures are checked at time of package install. So it seems like firefox merely needs to be taught that the pre-packaged extensions deployed by RPM are pre-verified, so it can skip its verification for those, while still doing verification for stuff that is live downloaded
Yes, that does seem like the most practical way and reasonably secure way to handle this; it might make Mozilla unhappy anyway.
Firefox is really doing this to fight malware that has probably actually received (possibly unintended) permission from the user to install itself into the system, which often includes getting Administrator rights. So, to mirror that Mozilla intent exactly, even RPM-deployed extensions should require a Mozilla signature.
OTOH, once you give malware root rights, it can in principle modify Firefox to skip the check, so this is only a hurdle, not a reliable feature. Equally, verifying the RPM extension contents against the RPM database and checking the RPM signature would be useless because the malware can just add its key to the keys RPM uses for verification.
The Mozilla blog also mentions some “third option” for “extensions that will never be publicly distributed and will never leave an internal network”, presumably bypassing the need to have them signed by Mozilla. Could that be used by Fedora?
There is a forum/faq answer somewhere that they will provide a signing server where you have to go through the same process as for normal extensions, only you do not end up publishing them.
I am not convinced this is a good idea, some people may simply not want to trust even mozilla (may have secrets stored in the extension or something), so I think mozilla should be smarter and allow people to install their own signing keys, or simply exempt signature checking if the extension is on disk. They should check on download only.
Simo.
On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
or simply exempt signature checking if the extension is on disk. They should check on download only.
That would defeat the entire purpose; malware is very commonly sideloading extensions.
Malware can easily binary patch firefox to ignore verification, I do not think trying to defeat sideloading with this kind of verification makes much sense. Of course you may decide to exempt only extensions in non-user-writable locations, if you are on Linux and the Firefox binary is read-only for the user.
Simo.
On 12/02/15 16:53, Simo Sorce wrote:
Malware can easily binary patch firefox to ignore verification, I do not think trying to defeat sideloading with this kind of verification makes much sense. Of course you may decide to exempt only extensions in non-user-writable locations, if you are on Linux and the Firefox binary is read-only for the user.
Besides the technical issues, what does upstream permit? Since we havn't re-branded firefox, are we free to modify this whatever way we want? I can see the argument for upstream to limit such modifications without re-branding.
Cheers!
--alec
On Thu, Feb 12, 2015 at 9:53 AM, Simo Sorce simo@redhat.com wrote:
Malware can easily binary patch firefox to ignore verification, I do not think trying to defeat sideloading with this kind of verification makes much sense.
And if you've already installed malware with on your computer, don't you kind of have bigger things to worry about than whether or not it can be loaded as a Firefox extension?
On 02/12/2015 04:53 PM, Simo Sorce wrote:
On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
or simply exempt signature checking if the extension is on disk. They should check on download only.
That would defeat the entire purpose; malware is very commonly sideloading extensions.
Malware can easily binary patch firefox to ignore verification,
Windows has Authenticode, which may change the equation somewhat.
I do not think trying to defeat sideloading with this kind of verification makes much sense.
Maybe it is only about preventing people from bundling the official Firefox version with dodgy add-ons. Not downright malware, but things users may not actually want without realizing it. The signature checking means that those who prepare the downloads can no longer use the unmodified upstream binary. Which in turn might force them not to use Mozilla brands.
Maybe this is a bit far-fetched, but after hours of staring at other people's code today, it seems pretty reasonable to me.
But what do add-on developers do? Surely there is a way to disable this somehow?
On Thu, 2015-02-12 at 18:19 +0100, Florian Weimer wrote:
On 02/12/2015 04:53 PM, Simo Sorce wrote:
On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
or simply exempt signature checking if the extension is on disk. They should check on download only.
That would defeat the entire purpose; malware is very commonly sideloading extensions.
Malware can easily binary patch firefox to ignore verification,
Windows has Authenticode, which may change the equation somewhat.
I do not think trying to defeat sideloading with this kind of verification makes much sense.
Maybe it is only about preventing people from bundling the official Firefox version with dodgy add-ons. Not downright malware, but things users may not actually want without realizing it. The signature checking means that those who prepare the downloads can no longer use the unmodified upstream binary. Which in turn might force them not to use Mozilla brands.
Maybe this is a bit far-fetched, but after hours of staring at other people's code today, it seems pretty reasonable to me.
But what do add-on developers do? Surely there is a way to disable this somehow?
Mozilla stated they will have to use the Developer Version (Aurora was the name ?) or the nightlies ...
Simo.
Am 12.02.2015 um 18:53 schrieb Simo Sorce:
Maybe it is only about preventing people from bundling the official Firefox version with dodgy add-ons. Not downright malware, but things users may not actually want without realizing it. The signature checking means that those who prepare the downloads can no longer use the unmodified upstream binary. Which in turn might force them not to use Mozilla brands.
Maybe this is a bit far-fetched, but after hours of staring at other people's code today, it seems pretty reasonable to me.
But what do add-on developers do? Surely there is a way to disable this somehow?
Mozilla stated they will have to use the Developer Version (Aurora was the name ?) or the nightlies ...
than Fedora needs to switch to the developer version if that *really* can't be disabled via about:config - that is a unacceptable restriction until hmtlvalidator, livehttpheaders and friends are available sigend via the mozilla page
On Thu, Feb 12, 2015 at 07:07:34PM +0100, Reindl Harald wrote:
Am 12.02.2015 um 18:53 schrieb Simo Sorce:
Maybe it is only about preventing people from bundling the official Firefox version with dodgy add-ons. Not downright malware, but things users may not actually want without realizing it. The signature checking means that those who prepare the downloads can no longer use the unmodified upstream binary. Which in turn might force them not to use Mozilla brands.
Maybe this is a bit far-fetched, but after hours of staring at other people's code today, it seems pretty reasonable to me.
But what do add-on developers do? Surely there is a way to disable this somehow?
Mozilla stated they will have to use the Developer Version (Aurora was the name ?) or the nightlies ...
than Fedora needs to switch to the developer version if that *really* can't be disabled via about:config - that is a unacceptable restriction until hmtlvalidator, livehttpheaders and friends are available sigend via the mozilla page
any news on that on our side? From firefox-devel I gather that the "feature" will land exactly as anounced.
There will be no configurable option for the user or sysadmin to allow loading of plugins not signed by mozilla - be it Fedora signed plugins or my personal bunch of homebrown locally built plugins.
So I think Fedora could provide 2 Firefox packages: * firefox-official with all restrictions * unbranded-firefoxlike-browser which is almost identical but without said restrictions
Richard
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
Mozilla states that they will be offering an unbranded binary (en_US only) for development and testing purposes.
Dne 26.8.2015 v 14:12 Alexander Ploumistos napsal(a):
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
Mozilla states that they will be offering an unbranded binary (en_US only) for development and testing purposes.
For example, I am using "GitHub Extension Installer" [1] to install development versions of several other add-ons directly from GH. I am afraid this won't be possible anymore.
Vít
[1] https://addons.mozilla.org/cs/firefox/addon/github-extension-installer/
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla.
Mozilla states that they will be offering an unbranded binary (en_US only) for development and testing purposes.
For me this appears the only possibility and I suspect there are more Fedora users like me maintaining their own Firefox extensions.
So will we get a firefox-unbranded package?
Richard
On Wed, Aug 26, 2015 at 3:13 PM, Richard Z rz@linux-m68k.org wrote:
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla.
Mozilla states that they will be offering an unbranded binary (en_US only) for development and testing purposes.
For me this appears the only possibility and I suspect there are more Fedora users like me maintaining their own Firefox extensions.
So will we get a firefox-unbranded package?
A better solution would be to add a mechanism that allows you to use your own signing keys. That way you have both 1) install self built extensions and 2) the added security.
On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote:
On Wed, Aug 26, 2015 at 3:13 PM, Richard Z rz@linux-m68k.org wrote:
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla.
Mozilla states that they will be offering an unbranded binary (en_US only) for development and testing purposes.
For me this appears the only possibility and I suspect there are more Fedora users like me maintaining their own Firefox extensions.
So will we get a firefox-unbranded package?
A better solution would be to add a mechanism that allows you to use your own signing keys.
which would be possible only with firefox-unbranded unless some wonder happens.
That way you have both 1) install self built extensions and 2) the added security.
might be a security gain for some people but not for me.
Richard
On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote:
A better solution would be to add a mechanism that allows you to use your own signing keys. That way you have both 1) install self built extensions and 2) the added security.
..and (3) a way for malware to install its own key, rendering (2) moot.
- Solomon
Am 27.08.2015 um 02:21 schrieb Solomon Peachy:
On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote:
A better solution would be to add a mechanism that allows you to use your own signing keys. That way you have both 1) install self built extensions and 2) the added security.
..and (3) a way for malware to install its own key, rendering (2) moot
that would imply that malware running as root and then you have already lost the whole game - pretty sure nobody meant "your own signing keys" writeable by the user firefox is running
On Thu, Aug 27, 2015 at 02:28:48AM +0200, Reindl Harald wrote:
Am 27.08.2015 um 02:21 schrieb Solomon Peachy:
On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote:
A better solution would be to add a mechanism that allows you to use your own signing keys. That way you have both 1) install self built extensions and 2) the added security.
..and (3) a way for malware to install its own key, rendering (2) moot
that would imply that malware running as root and then you have already lost the whole game - pretty sure nobody meant "your own signing keys" writeable by the user firefox is running
I suspect even malware with user rights will be able to effectively manipulate the firefox binary using LD_PRELOAD or many other methods.
Having a working sandbox implementation would improve security much better.
Richard
There can be alternative authorities, and you could opt to choose them nstead. It's really a question of having the option of not relying on Mozilla's decisions. It's not a choice of either each individual's own keys or the "original authority who's the one true authority." Self-signing means choosing who to trust.
The alternative authorities become explicit targets from the perspective of Mozilla, of course. So political commitment is entailed.
It should be noted that this distinction is important: the legal tradition does NOT hold that the only valid authority regarding what you can do with a work is the author. There's lots you can do that the author doesn't authorize; and authors only have specific statutory exclusive rights.
Among other things, this reflects a respect for the fact that information as such is not subject to copyright; just the originality of a work is. However, we are at a phase where an attempt to institute enforcement of the maximalist intepretation of copyright is imminent.
Seth
On Wed, Aug 26, 2015 at 8:21 PM, Solomon Peachy pizza@shaftnet.org wrote:
On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote:
A better solution would be to add a mechanism that allows you to use your own signing keys. That way you have both 1) install self built extensions and 2) the added security.
..and (3) a way for malware to install its own key, rendering (2) moot.
- Solomon
-- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Wednesday, August 26, 2015 03:13:08 PM Richard Z wrote:
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla.
We have no real practical way to do this other than package up the addon and build it as a -unsigned package, then making a separate package that has the precompiled binary and signed by mozilla and put into the add on package.
It sounds like the path mozilla is taking will likely prevent us shipping addons in Fedora. That of course is their right to pursue that.
Mozilla states that they will be offering an unbranded binary (en_US only) for development and testing purposes.
For me this appears the only possibility and I suspect there are more Fedora users like me maintaining their own Firefox extensions.
So will we get a firefox-unbranded package?
Richard
Dne 27.8.2015 v 16:09 Dennis Gilmore napsal(a):
On Wednesday, August 26, 2015 03:13:08 PM Richard Z wrote:
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla.
We have no real practical way to do this other than package up the addon and build it as a -unsigned package, then making a separate package that has the precompiled binary and signed by mozilla and put into the add on package.
It sounds like the path mozilla is taking will likely prevent us shipping addons in Fedora. That of course is their right to pursue that.
I'm wondering what is good replacement option - since the amount of troubles with Firefox seems to be just scaling up.
The memory usage - is the story for it self - displaying a tab with just our bugzilla pages eats like 6-8M of RAM - I used to be running full OS with this amount of RAM - now it's not enough to render couple lines and color boxes and 'couple' KB of text....
Keyboard and mouse has weird focus - so often I type in one windows, but keyboard input magically work in another window (i.e. Ctrl+T opens new tab in second window)
I've no chance to control what is downloaded - I could partially limit thing by using plugins - but they eats possibly more RAM, slows FF down (at least by FF reporting messages) and will likely be sooner or later banned.
Lot's of things are hardly reportable.
Chrome is not an option for me - it eats even more RAM and slows my machine even more then FF.
So what are the option - if the person want to view Web with all modern technologies being supported ?
Zdenek
On 27 August 2015 at 08:26, Zdenek Kabelac zkabelac@redhat.com wrote:
Dne 27.8.2015 v 16:09 Dennis Gilmore napsal(a):
On Wednesday, August 26, 2015 03:13:08 PM Richard Z wrote:
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:
Their FAQ is constantly updated:
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
I'm not sure if there is a valid practical reason to refuse submitting the addons that we ship to their signing service or if it is against our policies; at least mozilla-https-everywhere has been signed.
that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla.
We have no real practical way to do this other than package up the addon and build it as a -unsigned package, then making a separate package that has the precompiled binary and signed by mozilla and put into the add on package.
It sounds like the path mozilla is taking will likely prevent us shipping addons in Fedora. That of course is their right to pursue that.
I'm wondering what is good replacement option - since the amount of troubles with Firefox seems to be just scaling up.
The memory usage - is the story for it self - displaying a tab with just our bugzilla pages eats like 6-8M of RAM - I used to be running full OS with this amount of RAM - now it's not enough to render couple lines and color boxes and 'couple' KB of text....
Keyboard and mouse has weird focus - so often I type in one windows, but keyboard input magically work in another window (i.e. Ctrl+T opens new tab in second window)
I've no chance to control what is downloaded - I could partially limit thing by using plugins - but they eats possibly more RAM, slows FF down (at least by FF reporting messages) and will likely be sooner or later banned.
Lot's of things are hardly reportable.
Chrome is not an option for me - it eats even more RAM and slows my machine even more then FF.
So what are the option - if the person want to view Web with all modern technologies being supported ?
You can't have that last part with the first parts. If you require the 'modern' technologies then you have to put up with their RAM/CPU eating glory.
Or start from scratch and see if you can build a toolkit that does it better.
Am 27.08.2015 um 16:26 schrieb Zdenek Kabelac:
Chrome is not an option for me - it eats even more RAM and slows my machine even more then FF.
So what are the option - if the person want to view Web with all modern technologies being supported ?
simple answer: there is no option, we are in the days of bloatware and as long as developers are not forced to work with machoines having only 1 GB RAM that sadly won't change back to sane development
On Thu, Aug 27, 2015 at 5:09 PM, Dennis Gilmore dennis@ausil.us wrote:
We have no real practical way to do this other than package up the addon and build it as a -unsigned package, then making a separate package that has the precompiled binary and signed by mozilla and put into the add on package.
Aren't the addons that we ship in fedora a bunch of text files zipped in an xpi archive? It is kind of awkward to send them back and forth, but if there are no other binaries, does it go against a particular policy?
Or we could decide that we trust Mozilla's code review process and drop packaging addons altogether, as was suggested. At least the users will receive updates faster.
On Thursday, August 27, 2015 05:40:18 PM Alexander Ploumistos wrote:
On Thu, Aug 27, 2015 at 5:09 PM, Dennis Gilmore dennis@ausil.us wrote:
We have no real practical way to do this other than package up the addon and build it as a -unsigned package, then making a separate package that has the precompiled binary and signed by mozilla and put into the add on package.
Aren't the addons that we ship in fedora a bunch of text files zipped in an xpi archive? It is kind of awkward to send them back and forth, but if there are no other binaries, does it go against a particular policy?
I have no idea what they actaully are as I have not looked, but the issues from the build perspective is that the builders have extremely limited network access, and the buildroot itself has none. we have no way to do something at build time to request mozilla sign the artifacts. so being unable to sign at buildtime means we get a rpm with unsigned content.
we have no way to replace the content in a rpm post build and even if we did I would not want to support it as it breaks things like rpm verification and build reproducability, though you could update the headers in the rpm so it validates. we would need some kind of audit trail and check to make sure that the signed artifact actually matches the unsigned one and was not tampered with by mozilla. setting up the full audit trail would take some effort. It is doable just not a simple fix.
Or we could decide that we trust Mozilla's code review process and drop packaging addons altogether, as was suggested. At least the users will receive updates faster.
depends on what was pushed to mozilla's addons, It could be possible for Fedora to have newer code than whats available from mozilla and vice versa. there is nothing today stopping people pulling addons directly from Mozilla and never using the version we build
Dennis
On 08/27/2015 04:40 PM, Alexander Ploumistos wrote:
Aren't the addons that we ship in fedora a bunch of text files zipped in an xpi archive? It is kind of awkward to send them back and forth, but if there are no other binaries, does it go against a particular policy?
Or we could decide that we trust Mozilla's code review process and drop packaging addons altogether, as was suggested. At least the users will receive updates faster.
Can we ship addons which are already signed by Mozilla? Or does Fedora packager modify them somehow?
ma.
On Fri, Aug 28, 2015 at 10:18 AM, Martin Stransky stransky@redhat.com wrote:
Can we ship addons which are already signed by Mozilla? Or does Fedora packager modify them somehow?
It seems that even when the source is an xpi file, rpm treats it like any other source package and its contents can be patched. I don't know how that works, because signed addons contain a manifest file with md5 and sha1 checksums for all included files and I would expect that modifications to any of them would cause the addon to get disabled. Obviously we need input from a packager involved with the process. Asking legal couldn't hurt either.
I think that these are all the addons that we ship and must be signed (dictionaries, themes and plugins are exempt from the signing process): http://pkgs.fedoraproject.org/cgit/firefox-esteidpkcs11loader.git/ http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/ http://pkgs.fedoraproject.org/cgit/mozilla-https-everywhere.git/ http://pkgs.fedoraproject.org/cgit/mozilla-noscript.git/ http://pkgs.fedoraproject.org/cgit/mozilla-requestpolicy.git/ http://pkgs.fedoraproject.org/cgit/spice-xpi.git/
On 08/28/2015 11:00 AM, Alexander Ploumistos wrote:
On Fri, Aug 28, 2015 at 10:18 AM, Martin Stransky stransky@redhat.com wrote:
Can we ship addons which are already signed by Mozilla? Or does Fedora packager modify them somehow?
It seems that even when the source is an xpi file, rpm treats it like any other source package and its contents can be patched. I don't know how that works, because signed addons contain a manifest file with md5 and sha1 checksums for all included files and I would expect that modifications to any of them would cause the addon to get disabled. Obviously we need input from a packager involved with the process. Asking legal couldn't hurt either.
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
ma.
I think that these are all the addons that we ship and must be signed (dictionaries, themes and plugins are exempt from the signing process): http://pkgs.fedoraproject.org/cgit/firefox-esteidpkcs11loader.git/ http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/ http://pkgs.fedoraproject.org/cgit/mozilla-https-everywhere.git/ http://pkgs.fedoraproject.org/cgit/mozilla-noscript.git/ http://pkgs.fedoraproject.org/cgit/mozilla-requestpolicy.git/ http://pkgs.fedoraproject.org/cgit/spice-xpi.git/
On Fri, Aug 28, 2015 at 12:24 PM, Martin Stransky stransky@redhat.com wrote:
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
That depends on the extension and its particulars. For example, adblock plus has an extortion-like scheme in place and it allows certain ads from certain companies that have paid them good money for their service. This patch blocks those ads as well: http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/tree/disable-safe... I didn't care to check if such a modification is permitted by their TOS.
On 08/28/2015 11:34 AM, Alexander Ploumistos wrote:
On Fri, Aug 28, 2015 at 12:24 PM, Martin Stransky stransky@redhat.com wrote:
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
That depends on the extension and its particulars. For example, adblock plus has an extortion-like scheme in place and it allows certain ads from certain companies that have paid them good money for their service. This patch blocks those ads as well: http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/tree/disable-safe... I didn't care to check if such a modification is permitted by their TOS.
Hm, is such change actually allowed by AddBlock authors? It looks a bit controversial to me. The extension signing may also help users to make sure they have the original extensions from their authors.
ma.
Martin Stransky stransky@redhat.com wrote:
On 08/28/2015 11:34 AM, Alexander Ploumistos wrote:
adblock plus [...] allows certain ads from certain companies [...] This patch blocks those ads as well: http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/tree/disable-safe... I didn't care to check if such a modification is permitted by their TOS.
Hm, is such change actually allowed by AddBlock authors?
If it weren't allowed, then Adblock Plus would be unfree and therefore not allowed in Fedora. On the front page at https://adblockplus.org/ it says "It's free! (GPLv3)", so that would be contradictory.
Björn Persson
On Fri, 28 Aug, 2015 at 09:34:14 GMT, Alexander Ploumistos wrote:
On Fri, Aug 28, 2015 at 12:24 PM, Martin Stransky stransky@redhat.com wrote:
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
That depends on the extension and its particulars. For example, adblock plus has an extortion-like scheme in place and it allows certain ads from certain companies that have paid them good money for their service. This patch blocks those ads as well: http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/tree/disable-safe... I didn't care to check if such a modification is permitted by their TOS.
There's Adblock Edge[1] which is a fork without such "features". But it seems they have discontinuted in favor of uBlock Origin[2] (which also handles the Request Policy plugin; also pretty much discontinued upstream). Having used all four, uBlock Origin is certainly the best out of all of them.
--Ben
[1]https://addons.mozilla.org/en-US/firefox/addon/adblock-edge/ [2]https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
* Martin Stransky [28/08/2015 11:24] :
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
If there is a security issue with an extension, the packager might well want to distribute a patched version while waiting for a new release.
Emmanuel
On 08/28/2015 11:40 AM, Emmanuel Seyman wrote:
- Martin Stransky [28/08/2015 11:24] :
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
If there is a security issue with an extension, the packager might well want to distribute a patched version while waiting for a new release.
That's possible but the update process in Fedora is recently too slow. Even Firefox security updates sits in testing for week. I bet that official update from AMO (mozilla extension site) will be way faster that Fedora update.
ma.
* Martin Stransky [28/08/2015 12:21] :
On 08/28/2015 11:40 AM, Emmanuel Seyman wrote:
- Martin Stransky [28/08/2015 11:24] :
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
If there is a security issue with an extension, the packager might well want to distribute a patched version while waiting for a new release.
That's possible but the update process in Fedora is recently too slow. Even Firefox security updates sits in testing for week.
I'm not seeing this, at least as a general rule. Most firefox updates seem to be pushed within a day.
I bet that officialupdate from AMO (mozilla extension site) will be way faster that Fedora update.
I suspect this will vary greatly depending on the maintainer and the security issue.
Emmanuel
Am 28.08.2015 um 13:39 schrieb Emmanuel Seyman:
- Martin Stransky [28/08/2015 12:21] :
On 08/28/2015 11:40 AM, Emmanuel Seyman wrote:
- Martin Stransky [28/08/2015 11:24] :
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
If there is a security issue with an extension, the packager might well want to distribute a patched version while waiting for a new release.
That's possible but the update process in Fedora is recently too slow. Even Firefox security updates sits in testing for week.
I'm not seeing this, at least as a general rule. Most firefox updates seem to be pushed within a day
guess you can trust the maintainer of the firefox package when he says it's slow :-) within a day is mostly impossible because of testing, karma and the timeframes for pushes
within a day is only possible if you download the build manually from koji
On Friday, August 28, 2015 01:43:08 PM Reindl Harald wrote:
Am 28.08.2015 um 13:39 schrieb Emmanuel Seyman:
- Martin Stransky [28/08/2015 12:21] :
On 08/28/2015 11:40 AM, Emmanuel Seyman wrote:
- Martin Stransky [28/08/2015 11:24] :
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
If there is a security issue with an extension, the packager might well want to distribute a patched version while waiting for a new release.
That's possible but the update process in Fedora is recently too slow. Even Firefox security updates sits in testing for week.
I'm not seeing this, at least as a general rule. Most firefox updates seem to be pushed within a day
guess you can trust the maintainer of the firefox package when he says it's slow :-) within a day is mostly impossible because of testing, karma and the timeframes for pushes
within a day is only possible if you download the build manually from koji
the last firefox update was on the mirrors within 5 hours of being built in koji
Dennis
On Friday, 28 August 2015 at 11:24, Martin Stransky wrote:
On 08/28/2015 11:00 AM, Alexander Ploumistos wrote:
On Fri, Aug 28, 2015 at 10:18 AM, Martin Stransky stransky@redhat.com wrote:
Can we ship addons which are already signed by Mozilla? Or does Fedora packager modify them somehow?
It seems that even when the source is an xpi file, rpm treats it like any other source package and its contents can be patched. I don't know how that works, because signed addons contain a manifest file with md5 and sha1 checksums for all included files and I would expect that modifications to any of them would cause the addon to get disabled. Obviously we need input from a packager involved with the process. Asking legal couldn't hurt either.
Thanks for the info. Actually is there any reason why Fedora packager would need to modify the original extension?
Yes. Bundled JavaScript libraries are one example. Fedora-specific preferences would be another.
Regards, Dominik
On Fri, Aug 28, 2015 at 12:18 AM, Martin Stransky stransky@redhat.com wrote:
On 08/27/2015 04:40 PM, Alexander Ploumistos wrote:
Aren't the addons that we ship in fedora a bunch of text files zipped in an xpi archive? It is kind of awkward to send them back and forth, but if there are no other binaries, does it go against a particular policy?
Or we could decide that we trust Mozilla's code review process and drop packaging addons altogether, as was suggested. At least the users will receive updates faster.
Can we ship addons which are already signed by Mozilla? Or does Fedora packager modify them somehow?
Another thought: could we ask Mozilla for permission to exempt a specific directory (e.g. /usr/share/distro-firefox-extensions) from signature requirements for .xpi files that are owned by root?
After all, anyone who can drop root-owned files in there can just as easily replace the entire firefox binary.
--Andy
Dennis Gilmore wrote:
It sounds like the path mozilla is taking will likely prevent us shipping addons in Fedora. That of course is their right to pursue that.
As far as I can find out there are no plans to enforce this centralized signing in Seamonkey, and I suppose the Icecat folks are free to choose whether to do it or not.
I wonder if there will be any packagers interested in maintaining extensions for Seamonkey and Icecat if packaged extensions will no longer work in Firefox.
Björn Persson
On Thu, Feb 12, 2015 at 09:54:16AM -0500, Miloslav Trmač wrote:
or simply exempt signature checking if the extension is on disk. They should check on download only.
That would defeat the entire purpose; malware is very commonly sideloading extensions.
If we only exempt extensions installed by RPM it is reasonable to assume that our new package review process would have validated there is no malware present. Our package review process is serving the same kind of purpose as Mozilla's extension review & signing process.
Regards, Daniel
On 02/12/2015 11:15 AM, Nikos Roussos wrote:
On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth mike@cchtml.com wrote:
Is Fedora going to get authorization to build Firefox with a runtime disable option?
If the only way is to completely disable this feature, I'd prefer we don't. I wouldn't like for us to ship a less secure build of Firefox.
It's not the only way, you can also patch the Firefox binary on disk to disable the check. You can even run a copy in case you cannot modify the original version due to file system permissions.
This is why I don't see how this can be a security improvement, at least not on Fedora. If it really cannot be disabled, it will also cause problems for centrally managed Firefox deployments which need to pre-install add-ons into user profiles.
Nikos Roussos wrote:
If the only way is to completely disable this feature, I'd prefer we don't. I wouldn't like for us to ship a less secure build of Firefox.
After Restricted Boot, now Restricted Browser? No thanks! This "feature" needs to be disabled no matter whether it affects our packaged plugins or not.
Kevin Kofler
On Wed, Feb 11, 2015 at 10:30:11PM -0600, Michael Cronenworth wrote:
I'm sure those that need to know, know, but for those that haven't heard[1] Mozilla's official Firefox build will enforce addons to contain a Mozilla signature without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
I have created https://bugzilla.redhat.com/show_bug.cgi?id=1257566
Richard
-
Alec Leamas -
Alexander Ploumistos -
Andrew Lutomirski -
Ben Boeckel -
Björn Persson -
Daniel P. Berrange -
Dennis Gilmore -
Dominik 'Rathann' Mierzejewski -
drago01 -
Emmanuel Seyman -
Florian Weimer -
Kevin Kofler -
Martin Stransky -
Michael Catanzaro -
Michael Cronenworth -
Miloslav Trmač -
Nikos Roussos -
Reindl Harald -
Richard Z -
Seth Johnson -
Simo Sorce -
Solomon Peachy -
Stephen John Smoogen -
Vít Ondruch -
Zdenek Kabelac