rust-cbindgen did apply some breaking changes which requires the added
patch in order to compile until a firefox version with the fix gets
released. Firefox 63.0.3 is supposed to carry the required patches. This
should only be required for a short term.
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12392: Crash with nested event loops
When manipulating user events in nested loops while opening a document
through script, it is possible to trigger a potentially exploitable
crash due to poor event handling.
- CVE-2018-12393: Integer overflow during Unicode conversion while loading JavaScript
A potential vulnerability was found in 32-bit builds where an integer
overflow during the conversion of scripts to an internal UTF-16
representation could result in allocating a buffer too small for the
conversion. This leads to a possible out-of-bounds write.
Note: 64-bit builds are not vulnerable to this issue.
- CVE-2018-12395: WebExtension bypass of domain restrictions through header rewriting
By rewriting the Host request headers using the webRequest API, a
WebExtension can bypass domain restrictions through domain fronting.
This would allow access to domains that share a host that are
otherwise restricted.
- CVE-2018-12396: WebExtension content scripts can execute in disallowed contexts
A vulnerability where a WebExtension can run content scripts in
disallowed contexts following navigation or other events. This allows
for potential privilege escalation by the WebExtension on sites where
content scripts should not be run.
- CVE-2018-12397: Missing warning prompt when WebExtension requests local file access
A WebExtension can request access to local files without the warning
prompt stating that the extension will "Access your data for all
websites" being displayed to the user. This allows extensions to run
content scripts in local pages without permission warnings when a
local file is opened.
- CVE-2018-12389: Memory safety bugs fixed in Firefox ESR 60.3
Mozilla developers and community members Daniel Veditz and Philipp
reported memory safety bugs present in Firefox ESR 60.2. Some of these
bugs showed evidence of memory corruption and we presume that with
enough effort that some of these could be exploited to run arbitrary
code.
- CVE-2018-12390: Memory safety bugs fixed in Firefox 63 and Firefox ESR 60.3
Mozilla developers and community members Christian Holler, Bob Owen,
Boris Zbarsky, Calixte Denizet, Jason Kratzer, Jed Davis, Taegeon Lee,
Philipp, Ronald Crane, Raul Gurzau, Gary Kwong, Tyson Smith, Raymond
Forbes, and Bogdan Tara reported memory safety bugs present in Firefox
62 and Firefox ESR 60.2. Some of these bugs showed evidence of memory
corruption and we presume that with enough effort that some of these
could be exploited to run arbitrary code.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-27/
Misc cleanups, but mainly this:
Before:
- `version` could mean either Firefox or TorBrowser version,
- `configureFlags` was hacky.
Now:
- `ffversion` is Firefox version, `tbversion` is TorBrowser version,
- `configureFlags` is much less hacky.
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
Fixes#30285
Some things done:
- Add macOS frameworks needed
- Fix RUST_BINDGEN handling. We need to pass all of NIX_CFLAGS_COMPILE
to rust bindgen
- Add custom install phase for darwin
This makes the command ‘nix-env -qa -f. --arg config '{skipAliases =
true;}'’ work in Nixpkgs.
Misc...
- qtikz: use libsForQt5.callPackage
This ensures we get the right poppler.
- rewrites:
docbook5_xsl -> docbook_xsl_ns
docbook_xml_xslt -> docbook_xsl
diffpdf: fixup
In particular, this contains Firefox-related and libgcrypt updates.
Other larger rebuilds would apparently need lots of time to catch up
on Hydra, due to nontrivial rebuilds in other branches than staging.
The icons for Firefox are in a new location in the unwrapped package; the
wrapper is updated to reflect that. This should have no effect on other browers
that provide their own icons in the default XDG location.
This is optional (`libcardiacarrest` has a workaround for this bug
because there's `firefox-bin` that I can't fix), but with this applied things
are a bit smoother.
Since firefox 58.0.1 the google api key is now stored at an absolute
path ($TMPDIR/ga). Since variable expansion in `configureFlags` does not
really work (as expected) the build started failing when using the
legacy firefox build system. With the newer `./mach` based builds
firefox reads the configure flags from `.mozconfig` instead.
This commit moves the `with-google-api-keyfile=` setting into the
`preConfigure` phase where we can properly expand `$TMPDIR` into
whatever the path is.
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-346372756 we
have permission to use the official firefox branding.
Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
This reverts a part of commit 559433d0db.
The problem with removing those options completely is that without them
tor-browser's config differs from the official config (which may or may
not be a problem for fingerprinting).
Broken since #30143.
I can't say I understand why this combination is apparently unsupported.
i686-linux is a second-tier platform now, but firefox is still kept a
channel blocker...
Storing the build configuration caused Firefox to retain a dependency
on gcc, glibc.dev and icu4c.dev.
This reduces the size of the firefox closure from 587 to 415 MiB.
Also updates beta, nightly, nightlyBin, and bootstrap compilers.
Also updates the registry.
Also consolidates logic between bootstrap and nightlyBin compilers.
Also contains some miscellaneous cleanups.
Also patches firefox to build with the newer cargo
Set MOZ_APP_LAUNCHER for firefox as per [1] (see [2] for detailed discussion).
Firefox will recognise itself across verions, skipping the 'not-the-default-browser' prompt.
Firefox will also write sane paths to the generated desktop file, should someone ever set it as default through the 'not-the-default-browser' prompt.
Also removed the unnecessary libtrick cruft.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=611953
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=593948
