www-client/firefox-59.0 and www-client/firefox-bin-59.0 were released on 2018-03-13. https://www.mozilla.org/en-US/firefox/59.0/releasenotes/ https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/ CVE-2018-5127: Buffer overflow manipulating SVG animatedPathSegList CVE-2018-5128: Use-after-free manipulating editor selection ranges CVE-2018-5129: Out-of-bounds write with malformed IPC messages CVE-2018-5130: Mismatched RTP payload type can trigger memory corruption CVE-2018-5131: Fetch API improperly returns cached copies of no-store/no-cache resources CVE-2018-5132: WebExtension Find API can search privileged pages CVE-2018-5133: Value of the app.support.baseURL preference is not properly sanitized CVE-2018-5134: WebExtensions may use view-source: URLs to bypass content restrictions CVE-2018-5135: WebExtension browserAction can inject scripts into unintended contexts CVE-2018-5136: Same-origin policy violation with data: URL shared workers CVE-2018-5137: Script content can access legacy extension non-contentaccessible resources CVE-2018-5138: Android Custom Tab address spoofing through long domain names CVE-2018-5140: Moz-icon images accessible to web content through moz-icon: protocol CVE-2018-5141: DOS attack through notifications Push API CVE-2018-5142: Media Capture and Streams API permissions display incorrect origin with data: and blob: URLs CVE-2018-5143: Self-XSS pasting javascript: URL with embedded tab into addressbar CVE-2018-5126: Memory safety bugs fixed in Firefox 59 New: Performance enhancements: - Faster load times for content on the Firefox Home page - Faster page load times by loading either from the networked cache or the cache on the user’s hard drive (Race Cache With Network) - Improved graphics rendering using Off-Main-Thread Painting (OMTP) for Mac users (OMTP for Windows was released in Firefox 58) Drag-and-drop to rearrange Top Sites on the Firefox Home page, and customize new windows and tabs in other ways Added features for Firefox Screenshots: - Basic annotation lets the user draw on and highlight saved screenshots - Recropping to change the viewable area of saved screenshots Enhanced WebExtensions API including better support for decentralized protocols and the ability to dynamically register content scripts Improved Real-Time Communications (RTC) capabilities. - Implemented RTP Transceiver to give pages more fine grained control over calls - Implemented features to support large scale conferences Added support for W3C specs for pointer events and improved platform integration with added device support for mouse, pen, and touch screen pointer input Added the Ecosia search engine as an option for German Firefox Added the Qwant search engine as an option for French Firefox Added settings in about:preferences to stop websites from asking to send notifications or access your device’s camera, microphone, and location, while still allowing trusted websites to use these features Reproducible: Always
Strange mozilla.org: Upstream there is no source directory any more: https://archive.mozilla.org/pub/firefox/releases/59.0.1/source/ But overlay ebuild use kind of a checksum to download from upstream hg
Source seems to be moved: https://archive.mozilla.org/pub/firefox/releases/59.0.1/SOURCE
*** Bug 650774 has been marked as a duplicate of this bug. ***
@Marcin yeah, the only chance now is to get a source line from that SOURCE file! Please don't wait for an esr release of version 59 Mozilla.org postponed that to may for version 60
Created attachment 524634 [details, diff] Diff between firefox-59.0_beta14.ebuild and firefox-59.0.1.ebuild FWIW, if you rename firefox-59.0_beta14.ebuild to firefox-59.0.1.ebuild and apply attached diff, you can install firefox 59.0.1.
Is there a reason for such a huge delay? I understand that people are busy, but there are issues marked as critical.
These bumps/commits have generally been my responsibility, but I'm on a health-related leave and can't dedicate the necessary time to do them (or anything else gentoo). Other members of mozilla@ haven't been able to do it so far. Version 59 is also somewhat tricky because Mozilla upstream stopped generating tarballs and currently (until v61 it seems :( ..) rely on an auto-generation that isn't deterministic. So gentoo will have to create and mirror a specific tarball on its own as well to avoid random digest errors (and the legality of this will need to be re-checked as well against the latest MPL).. It's administrivia, but necessary nevertheless.
MS Teams just stopped working with 58.0.1 so an update is much appreciated
@Ian the ebuild generated from the patch of @Andrzej comment5 gives me a stable checksum: After two days I have moved away the Manifest and the source tarball and renewed "ebuild firefox-59.0.1.ebuild manifest" in my overlay. Gives me the same b2sum: --- # b2sum /var/distfiles/firefox-59.0.1.source.tar.bz2 /var/firefox-59.0.1.source.tar.bz2 9607f21ca421ab9989a74671b7fc76acfbfc6e971dd078c954e0435a75e2e8855cd959178a473ab02c43c70bfd540d948e88d0548c7df26f329fcebc2b97e895 /var/distfiles/firefox-59.0.1.source.tar.bz2 9607f21ca421ab9989a74671b7fc76acfbfc6e971dd078c954e0435a75e2e8855cd959178a473ab02c43c70bfd540d948e88d0548c7df26f329fcebc2b97e895 /var/firefox-59.0.1.source.tar.bz2
(In reply to Ulenrich from comment #9) > After two days I have moved away the Manifest and the > source tarball and renewed "ebuild firefox-59.0.1.ebuild manifest" in my > overlay. Gives me the same b2sum: > --- It changes once every while; probably once the tarball is evicted from cache e.g. b2sum firefox-59.0.1.source.tar.bz2 from March 16. b19c0710766d9f03ae181ada802bda8779f2ac3e4ded8b33bd31d674ac26aa5f1240c2a7bc34a58297c6f720602f7b5e8a773eeca8d0239104f21177e27b070b
(In reply to Sven B. from comment #10) > It changes once every while; probably once the tarball is evicted from cache > e.g. b2sum firefox-59.0.1.source.tar.bz2 from March 16. > b19c0710766d9f03ae181ada802bda8779f2ac3e4ded8b33bd31d674ac26aa5f1240c2a7bc34a > 58297c6f720602f7b5e8a773eeca8d0239104f21177e27b070b Then again maybe not seems i checked out a different tarball (pre official release, once it was listed on archive.m.o) with a single tag change or alternative the tarballs stay consistent unless a tag change is done. --- march16/mozilla-release-3db9e3d52b17563efca181ccbb50deb8660c59ae/.hg_archival.txt2018-03-15 23:12:05.000000000 +0100 +++ current/mozilla-release-3db9e3d52b17563efca181ccbb50deb8660c59ae/.hg_archival.txt 2018-03-15 23:12:05.000000000 +0100 @@ -1,7 +1,5 @@ repo: 8ba995b74e18334ab3707f27e9eb8f4e37ba3d29 node: 3db9e3d52b17563efca181ccbb50deb8660c59ae branch: default -latesttag: FENNEC_59_0_BUILD3 -latesttag: FENNEC_59_0_RELEASE -latesttagdistance: 5 -changessincelatesttag: 5 +tag: FIREFOX_59_0_1_BUILD1 +tag: FIREFOX_59_0_1_RELEASE
Currently, we are expected to fetch a tarball from mercurial interface directly. Mercurial is very similar to git in many regards, including the following one: mercurial hashes both the contents of an object and the hash of its parents to create an identifier that uniquely identifies an object's contents and history [1]. This means fetching a specific revision like https://hg.mozilla.org/releases/mozilla-release/archive/3db9e3d52b17563efca181ccbb50deb8660c59ae.tar.gz [2] must never produce different results unless some malfunction happens. There are also named tags (like FIREFOX_59_0_1_RELEASE). They can be rewritten to point to a different revision, but this is considered a bad practice, especially when talking about releases. Possible explanations for different results might include: using a wrong repository (ie not mozilla-release), using a tag while the tag is rewritten. Note: we might use a tag instead of a revision hash: https://hg.mozilla.org/releases/mozilla-release/archive/FIREFOX_59_0_1_RELEASE.tar.gz [1] https://www.mercurial-scm.org/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F [2] from https://archive.mozilla.org/pub/firefox/releases/59.0.1/SOURCE
Well, another thing to consider. While content of files remains the same, the resulting archive is not guaranteed to be the same. It is not stored on the disk, but generated on-fly -- there are signs of that: HTTP request sent, awaiting response... 200 Script output follows Length: unspecified [application/x-gzip] Like 1) "script output" and 2) the length is not specified (ie streaming). This might result in files simply being compressed in a different order (or with different metadata), which means a different hash.
I tried like explained in comment #5. However, it seems that the language extensions don't work. I have set L10N="fr" but firefox is only installed in english.
(In reply to François Valenduc from comment #14) > I tried like explained in comment #5. However, it seems that the language > extensions don't work. I have set L10N="fr" but firefox is only installed in > english. Did you emerge a _beta ebuild or firefox-59.0.1.ebuild since L10N isn't taken into account on _beta versions; AFAIK. Also 59.0.2 is already in rc1, and is likely to be available in a few hours on archive.m.o.
I did like explained in comment #5. I got the firefox-59.0_beta14.ebuild from the git tree, renamed it to firefox-59.0.1 ebuild and applied the diff. So this might be the reason since it was initially a beta ebuild ?
(In reply to François Valenduc from comment #16) > I did like explained in comment #5. I got the firefox-59.0_beta14.ebuild > from the git tree, renamed it to firefox-59.0.1 ebuild and applied the diff. > So this might be the reason since it was initially a beta ebuild ? No, that should be fine. If the language pack is installed ( check firefox -> addons -> languages or /usr/lib64/firefox/browser/extensions/* ) firefox should choose the language set by the os. That can be overwritten in about:config if needed. ( https://support.mozilla.org/en-US/kb/use-firefox-interface-other-languages-language-pack ) ;
I revert back to firefox and the intl.locale.requested setting was present and set to fr. After installing firefox 59.0.1, the setting disapperead. I added it again and set it to 'fr', so it works. But I found rather strange that it had been removed.
(In reply to Ulenrich from comment #9) > @Ian the ebuild generated from the patch of @Andrzej comment5 gives me a > stable checksum: After two days I have moved away the Manifest and the > source tarball and renewed "ebuild firefox-59.0.1.ebuild manifest" in my > overlay. Gives me the same b2sum: > --- > # b2sum /var/distfiles/firefox-59.0.1.source.tar.bz2 > /var/firefox-59.0.1.source.tar.bz2 > 9607f21ca421ab9989a74671b7fc76acfbfc6e971dd078c954e0435a75e2e8855cd959178a473 > ab02c43c70bfd540d948e88d0548c7df26f329fcebc2b97e895 > /var/distfiles/firefox-59.0.1.source.tar.bz2 > 9607f21ca421ab9989a74671b7fc76acfbfc6e971dd078c954e0435a75e2e8855cd959178a473 > ab02c43c70bfd540d948e88d0548c7df26f329fcebc2b97e895 > /var/firefox-59.0.1.source.tar.bz2 Today again the same b2sum, when downloading: 9607f21ca421ab9989a74671b7fc76acfbfc6e971dd078c954e0435a75e2e8855cd959178a473ab02c43c70bfd540d948e88d0548c7df26f329fcebc2b97e895
Is binary version affected by the described issue with hashes as well?
(In reply to Gleb from comment #20) > Is binary version affected by the described issue with hashes as well? A binary version never is created on the fly from version control system
There is 59.0.2 at: https://archive.mozilla.org/pub/firefox/releases/59.0.2/SOURCE I took the new firefox-59.0.1.ebuild from the mozilla overlay - changend the name to firefox-59.0.2.ebuild - edited SRCHASH=239e434d6d2b8e1e2b697c3416d1e96d48fe98e5 - ebuild firefox-59.0.2.ebuild manifest - and emerged firefox runs perfectly! One final question: Could I configure USE custom-cflags or custom-optimization to mitigate spectre kind leak of data ???
> One final question: Could I configure USE custom-cflags or custom-optimization to mitigate spectre kind leak of data ??? You would need to look at -mindirect-branch, -mindirect-branch-loop, -mfunction-return, -mindirect-branch-register options. Last time I tried this, rust integration crashed during the build, but maybe things have changed since then.
(In reply to Ulenrich from comment #22) > > One final question: Could I configure USE custom-cflags or > custom-optimization > to mitigate spectre kind leak of data ??? Yes, enable custom-cflags and use package.env to switch cflags for firefox. Last time I checked the forums, recommended EXTRA flags were: -fstack-protector-all -fno-plt -mindirect-branch=thunk -mfunction-return=thunk but Im not sure about the latest line you should use.
Please ask for help on the mailing list if you lack manpower, I'm sure enough people would be happy to help you.
mozilla overlay has firefox-59.0.2 but there is an issue with locales not being changed (ff always appears in eglish language). Once this has been fixed I gonna put the ebuild into ::gentoo unless our real ff maintainers don't beat me to it.
(In reply to Lars Wendler (Polynomial-C) from comment #26) > issue with locales not > being changed (ff always appears in eglish language) https://groups.google.com/forum/#!topic/firefox-dev/_qtfIyuXmYU tldr: Put an empty "intl.locale.requested" into the default prefs.js.
Unfortunately, after the recent commits in the mozilla overlay, the installed hunspell dictionaries aren't available any more. With the latest changes, only the English spell checking is available. After reverting the last two commits, all the installed spell checkers are shown again. firefox is installed with L10N="" hunspell is installed with L10N="de en fr"
The removal of pref("general.useragent.locale", "chrome://global/locale/intl.properties") seems to disable hunspell integration. This removal is unnecessary for the UI language. UI language and hunspell integration seem both to work on a fresh profile with the two settings: pref("intl.locale.requested", ""); pref("general.useragent.locale", "chrome://global/locale/intl.properties");
there is another issue with overlay ebuild after this commit https://cgit.gentoo.org/proj/mozilla.git/commit/?id=7bb771a5a29810e66a6e77a5662d0efdcfd0dfbf eme-free does not work as expected. emerging with USE=eme-free passes --enable-eme and vice versa. I think negative use flag should be change to normal. also, even If I build with eme-free (which erroneously will try to enable eme) drm is still not working. I don't know why. the only way I could make drm work in ff59 is putting back the line > use eme-free && mozconfig_annotate '+eme-free' --disable-eme
What happened to FF 59.0.2 in Gentoo? Seems like activity has stopped ...
So, of several hundred people with push access to the portage tree there is not a single one who is willing to bump to 59.0.2? This is a major component of most desktop installations, suffering from critical security vulnerabilities for over one month now. Related: bug 550424
(In reply to teefax from comment #32) > So, of several hundred people with push access to the portage tree there is > not a single one who is willing to bump to 59.0.2? > > This is a major component of most desktop installations, suffering from > critical security vulnerabilities for over one month now. I'm afraid teefax is right. More than a month later after the initial 59 release and still no ebuild at all. We all understand that this is voluntary work, but as teefax says the browser is an important part of the desktop. Someone should step forward and commit a initial ebuild, until a newer ebuild fixes all the issues that were described here. Thank you.
The firefox-bin package has been updated, at least. It only concerns the www-client/firefox package now.
This bug was opened on March 14th. Bumping Firefox to 59 (not mentioning 59.0.1 or even 59.0.2), includes critical security fixes listed in https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/. The chromium package which included security fixes too, was bumped one day later after the initial report (see bug 653696). So, this bug should have been assigned to Gentoo Security too, instead of the Mozilla team. We are approaching one and a half month later after the initial release and still no ebuild for a critical system component for the desktop user. I do not want to use the bin package (which was committed 14 days ago, still too late after the initial release). What is going on?
(In reply to Vasilis Lourdas from comment #35) > This bug was opened on March 14th. Bumping Firefox to 59 (not mentioning > 59.0.1 or even 59.0.2), includes critical security fixes listed in > https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/. > So, this bug should have been assigned > to Gentoo Security too, instead of the Mozilla team. No. Only the ESR version is stable and thus security supported (in terms of Gentoo Security team). That is all up to date (52.7.3 at the time of writing) and security supported by upstream. What is going on is that someone needs to fix the issues (localization and potentially eme-free issues, I gather). The usual person doing it is on devaway. Someone should step up. Meanwhile 59.0.x is available in the mozilla overlay, these warts included.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5021e95a40c125ad5d78f8d8e499362bced9a4d2 commit 5021e95a40c125ad5d78f8d8e499362bced9a4d2 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2018-04-25 10:19:13 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-04-25 10:20:51 +0000 www-client/firefox: Bump to version 59.0.2 Closes: https://bugs.gentoo.org/650472 Package-Manager: Portage-2.3.31, Repoman-2.3.9 www-client/firefox/Manifest | 93 ++++++ www-client/firefox/files/gentoo-default-prefs.js-2 | 17 + www-client/firefox/firefox-59.0.2.ebuild | 370 +++++++++++++++++++++ 3 files changed, 480 insertions(+)
