You can now optionally invoke update-source-versions with:
* --system flag changing the host platform, to be passed dirrectly to Nix commands.
This is useful for binary packages which have different sources for each platform.
* --file flag allowing to change the file to be modified. This is useful for packages
that offer multiple variants, listed in a different file than the derivation itself;
e.g. packages.nix of Sublime Text 3.
* --version-key, which is now a keyword flag instead of a positional argument.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
The firefox wrapper now supports setting the GDK_BACKEND to wayland
which is useful in cases where firefox would be started from within an
X-Application inside of wayland. GTK/GDK would otherwise default to the
X11 backend in those situations.
The intention is that people that are using wayland primarily pull in
the new `firefox-wayland` top-level attribute into their environments
instead of just `firefox`. Firefox will then always be started with the
correct rendering backend.
This adds support for building firefox with the gtk wayland backend. It
should work on all the flavors that use >=gtk3. Using the wayland
still allows using the X11 backend.
It works, but this state is far from ideal: GNU guys update generated source
tarballs very infrequently. Ideally, src needs to be generated by running
makeicecat over firefox src. Will do later.
There have been some more changes to the source tree which broke the
buildconfig patch. This commit adds another patch that can be used for
the future versions. Once all the flavors are based off a new(ish)
firefox release we can remove the old patch.
Firefox >=65 will depend on icu >=63. All the older firefox versions
(and derived packages) seem to work fine with this change.
Also the system path environment patch will fail to apply since there
was a trivial whitespace change in the source file. By adding `-l` to
patch we can avoid having to track two patches that do basically the
same. Having patchFlags per file without resorting to pre-/postPatch
would be nicer but there doesn't seem to be a facility for that right
now.
To make updating large attribute sets faster, the update scripts
are now run in parallel.
Please note the following changes in semantics:
- The string passed to updateScript needs to be a path to an executable file.
- The updateScript can also be a list: the tail elements will then be passed
to the head as command line arguments.
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.
