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)
stable 51.0.2704.63 => 51.0.2704.103
beta 51.0.2704.63 => 52.0.2743.41
dev 52.0.2743.10 => 53.0.2767.4
This addresses 15 security fixes, including:
* High CVE-2015-1696: Cross-origin bypass in Extension bindings. Credit to
anonymous.
* High CVE-2015-1697: Cross-origin bypass in Blink. Credit to Mariusz
Mlynski.
* Medium CVE-2016-1698: Information leak in Extension bindings. Credit to
Rob Wu.
* Medium CVE-2016-1699: Parameter sanitization failure in DevTools. Credit
to Gregory Panakkal.
* Medium CVE-2016-1700: Use-after-free in Extensions. Credit to Rob Wu.
* Medium CVE-2016-1701: Use-after-free in Autofill. Credit to Rob Wu.
* Medium CVE-2016-1702: Out-of-bounds read in Skia. Credit to cloudfuzzer.
See: http://googlechromereleases.blogspot.com/2016/06/stable-channel-update.html
With this update we need to rebase the nix_plugin_paths patch, which was
done by @srp and I took it from his comment at:
https://github.com/NixOS/nixpkgs/pull/15762#issuecomment-222230677
Other than that, using libjpeg from nixpkgs fails to link:
https://headcounter.org/hydra/build/1114273
Rather than just using versionAtLeast to check for >= version 52, we're
matching on the explicit version number. That way we can make sure that
we (try to) build with system libjpeg again so we can keep it out of the
overall Chromium build time.
Built and tested using the VM tests on my Hydra at:
https://headcounter.org/hydra/eval/322006
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're already on version 52, so there really is no need to keep all
those conditionals and old patches anymore.
Tested dropping the unconditional build_fixes_46.patch via the Chromium
VM tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm not sure how the wrong hash ended up being there, but I've checked
the hash from three different machines (and networks) just to be sure I
didn't make a mistake.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of updated versions:
stable: 50.0.2661.102 -> 51.0.2704.63
beta: 51.0.2704.47 -> 51.0.2704.63
I tried to update dev, but couldn't get it to compile, it was failing
with a "'isnan' was not declared in this scope.
As far as I can tell, at the moment the beta and stable channels are
on the same version.
The stable update addresses the following security issues:
* High CVE-2016-1672: Cross-origin bypass in extension bindings. Credit
to Mariusz Mlynski.
* High CVE-2016-1673: Cross-origin bypass in Blink. Credit to Mariusz
Mlynski.
* High CVE-2016-1674: Cross-origin bypass in extensions. Credit to Mariusz
Mlynski.
* High CVE-2016-1675: Cross-origin bypass in Blink. Credit to Mariusz
Mlynski.
* High CVE-2016-1676: Cross-origin bypass in extension bindings. Credit
to Rob Wu.
* Medium CVE-2016-1677: Type confusion in V8. Credit to Guang Gong of
Qihoo 360.
* High CVE-2016-1678: Heap overflow in V8. Credit to Christian Holler.
* High CVE-2016-1679: Heap use-after-free in V8 bindings. Credit to Rob Wu.
* High CVE-2016-1680: Heap use-after-free in Skia. Credit to Atte Kettunen
of OUSPG.
* High CVE-2016-1681: Heap overflow in PDFium. Credit to Aleksandar Nikolic
of Cisco Talos.
* Medium CVE-2016-1682: CSP bypass for ServiceWorker. Credit to
KingstonTime.
* Medium CVE-2016-1683: Out-of-bounds access in libxslt. Credit to Nicolas
Gregoire.
* Medium CVE-2016-1684: Integer overflow in libxslt. Credit to Nicolas
Gregoire.
* Medium CVE-2016-1685: Out-of-bounds read in PDFium. Credit to Ke Liu
of Tencent's Xuanwu LAB.
* Medium CVE-2016-1686: Out-of-bounds read in PDFium. Credit to Ke Liu
of Tencent's Xuanwu LAB.
* Medium CVE-2016-1687: Information leak in extensions. Credit to Rob Wu.
* Medium CVE-2016-1688: Out-of-bounds read in V8. Credit to Max Korenko.
* Medium CVE-2016-1689: Heap buffer overflow in media. Credit to Atte
Kettunen of OUSPG.
* Medium CVE-2016-1690: Heap use-after-free in Autofill. Credit to Rob Wu.
* Low CVE-2016-1691: Heap buffer-overflow in Skia. Credit to Atte Kettunen
of OUSPG.
* Low CVE-2016-1692: Limited cross-origin bypass in ServiceWorker. Credit
to Til Jasper Ullrich.
* Low CVE-2016-1693: HTTP Download of Software Removal Tool. Credit to
Khalil Zhani.
* Low CVE-2016-1694: HPKP pins removed on cache clearance. Credit to Ryan
Lester and Bryant Zadegan.
See: http://googlechromereleases.blogspot.com/2016/05/stable-channel-update_25.html
Overview of the updated versions:
beta: 50.0.2661.49 -> 51.0.2704.47
dev: 51.0.2693.2 -> 52.0.2729.3
It has been a while since we had a major Chromium update that compiled
and worked without troubles, but version 52 builds and the VM tests are
successful as well:
https://headcounter.org/hydra/eval/320335
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This addresses the following security fixes:
* High CVE-2016-1667: Same origin bypass in DOM. Credit to
Mariusz Mlynski.
* High CVE-2016-1668: Same origin bypass in Blink V8 bindings. Credit
to Mariusz Mlynski.
* High CVE-2016-1669: Buffer overflow in V8. Credit to Choongwoo Han.
* Medium CVE-2016-1670: Race condition in loader. Credit to anonymous.
* Medium CVE-2016-1671: Directory traversal using the file scheme on
Android. Credit to Jann Horn.
See: http://googlechromereleases.blogspot.com/2016/05/stable-channel-update.html
Signed-off-by: Scott R. Parish <srparish@gmail.com>
Tested-by: aszlig <aszlig@redmoonstudios.org>
Closes: #15446
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by f28b71023c.
Let's now expose and use the upstream-info attribute via the main
Chromium derivation, so that other packages like the google-chrome
package doesn't need to rely on internals of the Chromium
implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This effectively resets the attributes given at the point the main
<nixpkgs> is imported and thus for example is also reading in stuff like
~/.nixpkgs/config.nix again, which might lead to unexpected results.
We now only import <nixpkgs> now if the updater is auto-called (like in
update.sh), otherwise the required attributes are passed by callPackage
within the Chromium scope.
I remember noting about this a while ago either on IRC or on GitHub, but
I can't find it right now, so thanks to @obadz for reminding me about
this in #15225.
Tested this by running the updater and also using:
NIXPKGS_CONFIG=$(pwd)/broken.nix nix-instantiate --arg config {} -A chromium
The contents of broken.nix were:
EVALERR{
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #15225
It's not the job of Nixpkgs to distribute beta versions of upstream
packages. More importantly, building these delays channel updates by
several hours, which is bad for our security fix turnaround time.
Overview of the updated versions:
stable: 49.0.2623.87 -> 49.0.2623.110
beta: 50.0.2661.26 -> 50.0.2661.49
dev: 50.0.2661.18 -> 51.0.2693.2
Most notably, this includes a series of urgent security fixes:
* CVE-2016-1646: Out-of-bounds read in V8. Credit to Wen Xu from
Tencent KeenLab.
* CVE-2016-1647: Use-after-free in Navigation. Credit to anonymous.
* CVE-2016-1648: Use-after-free in Extensions. Credit to anonymous.
* CVE-2016-1649: Buffer overflow in libANGLE. Credit to lokihardt
working with HP's Zero Day Initiative / Pwn2Own.
* CVE-2016-1650: Denial of service in PageCaptureSaveAsMHTMLFunction
The official release announcement with details about these fixes can be
found here:
http://googlechromereleases.blogspot.de/2016/03/stable-channel-update_24.html
Beta and stable could be also affected, although I didn't do a detailed
check whether that's the case.
As this introduces Chromium 51 as the dev version, I had to make the
following changes to make it build:
* libexif got removed, so let's do that on our end as well.
See https://codereview.chromium.org/1803883002 for details.
* Chromium doesn't seem to compile with our version of libpng, so let's
resort to the bundled libpng for now.
* site_engagement_ui.cc uses isnan outside of std namespace, so
we're fixing that in postPatch using sed.
I have successfully built all versions on i686-linux and x86_64-linux
and tested it using the VM tests.
Test reports can be found at the following evaluation of my Hydra:
https://headcounter.org/hydra/eval/314584
Thanks to @grahamc for reporting this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Graham Christensen <graham@grahamc.com>
Fixes: #14299
I originally wanted to do this a long time (a31301d) but IIRC back then
it didn't compile. Nowadays with the splitup of the gold linking flags
and the binutils integration, it's merely just a switch to flip, so
let's do that.
Only tested it by building against the current Chromium stable version
on 64bit, because right now builds on Hydra seem to time out (because of
this?) anyway so we have nothing to lose here.
The linking time was hereby reduced from >30 minutes (I didn't measure
it exactly but looked half an hour later to the build progress and it
was *still* linking) to about a few seconds, which I guess is even
though the measurement is quite bogus a tremendous improvement
nonetheless.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As of 6041cfe, the upstream-info.nix (back then it was called
sources.nix) is no longer in the source/ subdirectory, so we need to fix
that comment to say that the file is autogenerated from update.sh in the
*same* directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 5979946c41.
I have tested this by building against the stable version of Chromium
and it seems to compile just fine, so it doesn't seem to be needed
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Only a aesthetics thingy, but also corrects the comment, because we're
essentially precompiling .py files, NOT the .pyc files (the latter are
the results).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
