requiredSystemFeatures is not a meta attribute but a derivation
attribute. So "big-parallel" was being ignored on e.g. chromium,
causing it to be built (and timing out) on slow machines.
http://hydra.nixos.org/build/45819778#tabs-buildsteps
Versions before 56 already had experimental support for Gtk 3 and since
version 56, Gtk 3 _seemed_ to become the default. Although it's now
requiring *both* Gtk 2 and Gtk3, so let's supply the dependency for now
to get it to build.
In the future however we might want to add use_gtk3 to the GN flags and
get rid of Gtk 2 completely.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Before version 54, the WideVine CDM plugin was built unconditionally and
it seems since version 54 this now is dependent upon a GYP/GN flag on
whether to include the CDM shared library or not.
Also, we now use a patch from Gentoo which should hopefully get the CDM
plugin to work properly, at least according to their bugtracker:
https://bugs.gentoo.org/show_bug.cgi?id=547630
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of updated versions:
stable: 54.0.2840.71 -> 54.0.2840.90
beta: 55.0.2883.21 -> 55.0.2883.35
dev: 56.0.2897.0 -> 56.0.2906.0
This is to get our Chromium versions in par with the latest upstream
ones before merging in the GN migration changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far we had the bundled Flash player plugin that came with Chrome, but
since version 54 the Chrome package doesn't include PPAPI Flash anymore.
Instead we're going to download the PPAPI Flash plugin directly from
Adobe and try to use them for all release channels of Chromium.
Of course it would be nice if we'd have an updater for it but for now
it's important that we don't break things for people who are currently
forced to use Flash.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Seems that these libraries aren't the ones Chromium is expecting to be,
so let's switch to use the bundled version of these libraries instead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Previously I've added the extra file common-gn.nix in addition to
common.nix, so we can possibly have a smooth transition from current
stable to the new version 54.
Unfortunately, version 53 is already EOL and we have to move to version
54 as soon as possible so we can only use GN and thus it doesn't make
sense to provide expressions for GYP anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should now be the upstream default and there also is no more flag
for GN to set it, so we'll no longer need it on our side as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This only uses the most basic GN flags which should represent the GYP
flags we had before. In order to get rid most of the GYP cruft, we now
have common.nix and common-gn.nix which are mostly the same, just that
the latter is only for GN builds.
The GN implementation is far from complete and currently not even
builds, so we need more work to get the beta and dev channels building.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It seems that upstream has re-uploaded the tarball again (see
0c2683cc11).
I've verified the new hash from two different hosts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The hash provided in commit 072917ea5d is
faulty, either because the upstream tarball has changed or because it
was wrong in the first place, no matter what happened we can't really
verify if we don't have the tarball with the old hash.
To double-check I've verified the hash against the one from Gentoo[1],
which has the following SHA256:
b46c26a9e773b2c620acd2f96d69408f14a279aefaedfefed002ecf898a1ecf2
After being converted into base 32 the hash does match with ours.
Note that I haven't tested building all Chromium channels (yet), but we
can fix upcoming issues later because right now it doesn't build anyway
because of the failing hash check.
[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/Manifest?id=2de0f5e4ffeb46a478c589b21d5bbcfd5736e57b
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes the following security problems:
- CVE-2016-5147: Universal XSS in Blink
- CVE-2016-5148: Universal XSS in Blink
- CVE-2016-5149: Script injection in extensions
- CVE-2016-5150: Use after free in Blink
- CVE-2016-5151: Use after free in PDFium
- CVE-2016-5152: Heap overflow in PDFium
- CVE-2016-5153: Use after destruction in Blink
- CVE-2016-5154: Heap overflow in PDFium
- CVE-2016-5155: Address bar spoofing
- CVE-2016-5156: Use after free in event bindings
- CVE-2016-5157: Heap overflow in PDFium
- CVE-2016-5158: Heap overflow in PDFium
- CVE-2016-5159: Heap overflow in PDFium
- CVE-2016-5160: Extensions web accessible resources bypass
- CVE-2016-5161: Type confusion in Blink.
- CVE-2016-5162: Extensions web accessible resources bypass
- CVE-2016-5163: Address bar spoofing
- CVE-2016-5164: Universal XSS using DevTools
- CVE-2016-5165: Script injection in DevTools
- CVE-2016-5166: SMB Relay Attack via Save Page As
- CVE-2016-5167: Various fixes from internal audits, fuzzing and other initiatives
This moves libsystemd.so and libudev.so into systemd.lib, and gets rid
of libudev (which just contained a copy of libudev.so and the udev
headers). It thus reduces the closure size of all packages that
(indirectly) depend on libsystemd, of which there are quite a few (for
instance, PulseAudio and dbus). For example, it reduces the closure of
Blender from 430.8 to 400.8 MiB.
Closes #17460
Changed the wrapper derivation to produce a second output containing the sandbox.
Add a launch wrapper to try and locate the sandbox (either in /var/setuid-wrappers or in /nix/store).
This launch wrapper also sheds libredirect.so from LD_PRELOAD as Chromium does not tolerate it.
Does not trigger a Chromium rebuild.
cc @cleverca22 @joachifm @jasom
First step towards addressing #17460
In order to be able to run the SUID sandbox, which is good for security
and required to run Chromium with any kind of reasonable sandboxing when
using grsecurity kernels, we want to be able to control where the
sandbox comes from in the Chromium wrapper. This commit patches the
appropriate bit of source and adds the same old sandbox to the wrapper
(so it should be a no-op)
