This reverts commit b7cbb4da11.
The main reason behind this - apart from looking ugly - is that it didn't really
solve anything, see:
http://hydra.nixos.org/build/4198299
So, we need a different and less hacky approach...
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So, this is our sledgehammer, forcing -fno-stack-protector for every gcc/g++ in
the univ... Chromium build. Of course this is a somewhat nasty fix and there
should be a real fix somewhere in Chromium 26. But instead of wandering around
and picking cherries, we now go out for the slaughter until someone brings us
the damn cherries because we are FUURRRIII... no well... time for sleep :-)
May the mighty Hydra be with us!
Thanks to our great fellow @cillianderoiste, for joining the battle with his
almighty battle axe, crushing and burning some CPUs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tested-by: Cillian de Róiste <cillian.deroiste@gmail.com>
This should at least mitigate our build error to only occur in v8 anymore.
Unfortunately we can't use v8 from nixpkgs right now, so we're going to put out
our sledgehammer in the next commit. Meanwhile, it doesn't hurt to get rid of
the bundled protobuf library, so let's do it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Unfortunately, we have build errors for version 25 in the bundled libvpx:
http://hydra.nixos.org/build/4173075http://hydra.nixos.org/build/4173066
As I can't reproduce this on my local system (I've disabled the option
CONFIG_CC_STACKPROTECTOR here), let's just hope that libvpx is the only part
that fails during build because of this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The upgrade currently doesn't involve the -lite package, as we need to use a few
more dependencies from nixpkgs first before we can finally fully switch over to
the lite package, even though the update script will try to fetch it anyway.
In this update, one particular problem that arises in conjuction with the
seccomp BPF sandbox is caused by this commit:
https://chromiumcodereview.appspot.com/12209029
Which particularily filters flags to the clone() syscall. I've spent (wasted?) a
few hours figuring out the troublesome flag, eventually figuring it out and -
just by curiousity ("Do other distributions have the same problem?") - searched
the web for "chromium CLONE_DETACHED" and BEHOLD...
A post from our OWN mailinglist pops up with the same patch I intended to do:
http://article.gmane.org/gmane.linux.distributions.nixos/10356
So shame on me for not being subscribed to the mailing list, and big thanks to
Ian Farmer for the patch.
As a consequence I'm now subscribed.
So, back to chromium itself, version 26 builds fine and works so far without
much (more to come in later commits) trouble.
We also had to introduce three more dependencies:
* protobuf: This one is because we don't need to use the bundled one anymore,
so we can use the version in nixpkgs.
* speechd: Not sure whether this was bundled or not, but let's use nixpkgs
version as well to keep down build time.
* libXdamage: Needed for screen capturing support.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This update is a bit more problematic, as the bundled version of libpng is
version 1.2.45 and the version in nixpkgs is 1.5.13. Even if trying to run with
libpng12 from nixpkgs, it seems to collide with parts of the bundled version.
So, until this is either fixed upstream or we have a good solution, we're using
bundled libpng for chromium version 25 and higher.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
For this update we needed to fix a bunch of things:
* Limit pulse_audio_fix.patch to version 24 only (fixed upstream in 25).
* Avoid the use of -fstack-protector for version 25.
The -fstack-protector option seems to be passed to libvpx now by default, so
simply use -fno-stack-protector in every occurence of -fstack-protector in
common.gypi. At least for now this will do it, but ultimately and for the future
we may want to have support for that in general.
And if we need that support in chromium directly depends on some of the next
updates to this package, as it seems that we now can switch to quite a lot of
nixpkgs dependencies instead of bundled dependencies.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Might come in handy to actually know when things going to break.
In case you're wondering: Yes, "aszlig" is the name everyone uses in real life
(even my family uses it) and is my pending stage name (not _yet_ officially).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The patch previously was fetched from an Arch Linux contributor but is no longer
available there anymore. So, this is only an intermediate fix until channels get
updated (very soon I hope, even though chromium 25 could get quite messy).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can still use the config attribute set from within all-packages to pass it to
the package expression, which we do in case of PulseAudio. In order to override
other stuff you can now conveniently use chromium.override without passing a
fake config attribute set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This allows for more flexible overrides instead of just passing a custom
configuration attrset like:
chromium.override { config.chromium.channel = "beta"; }
So you can now simply do:
chromium.override { channel = "beta"; }
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The patch is no longer needed, as we are now using the BPF seccomp sandbox.
Unfortunately this is not marked "adequately sandboxed" in chrome://sandbox, as
it awaits security review on http://crbug.com/26528.
Unfortunately this gets us into a position where we can't be sure if the sandbox
is working correctly, especially because the non-BPF seccomp sandbox has a bunch
of stability issues and is marked legacy. And we definitely don't want to add
support for the setuid sandbox, do we?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 23.0.1271.60 (build successful)
dev: 24.0.1312.2 (build successful after patching)
The development version needs a patch in order to build properly against
PulseAudio. Issue and origin of the patch can be found here:
http://crbug.com/157876
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 23.0.1271.26 -> 23.0.1271.40
dev: 24.0.1284.2 -> 24.0.1297.0
Both are building successful and the BPF seccomp sandbox fix has been dropped as
it has finally been applied upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The new version is the one already committed in trunk as revision 160697.
In order to get into beta and stable this could take some while so we're going
need to carry around that patch for some time.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This dependency has recently been added to chromium while we didn't notice it,
so let's avoid to use the bundled version.
It might make sense to remove the unneeded files in third_party/ based on a
whitelist, so that we notice future changes like this earlier.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
While libexif has been bundled with chromium for some months already, they only
recently added the GYP option to switch to using the system library. So, let's
enable it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Version 22 is the current version of the stable channel, so we don't need to
carry around a patch for earlier versions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This removes the patch introduced in 949afcc0f2.
The reason behind this is because even though we patch in the legacy seccomp
sandbox by default, it won't be used anyway as both cannot coexist anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is just a temporary fix and will only thrown away as soon as a proper fix
is included upstream, see http://crbug.com/149834 for more details about this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The BPF renderer sandbox is now the default in 23. But still, it is not regarded
as "adequately sandboxed" from Google so we still need the legacy seccomp
sandbox.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Well, after looking a bit more thoroughly through the zlib patch from the
Chromium team, it seams, that this really fix an issue that hasn't yet been
applied upstream. Unfortunately neither Chromium nor Zlib give more information
about that issue. Maybe they're waiting until its resolved upstream and thus the
temporary patch?
The bad news is, that the fix for the vulnerability is incomplete in Chromium
and covers only the use cases of Chromium itself, so we can't include that
patched version in nixpkgs zlib derivation.
Until the issue is fixed upstream we're hereby safer off turning it off in
Chromium and thus use the bundled and patched version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
dev: 23.0.1271.10
beta: 22.0.1229.91
stable: 22.0.1229.79
The revert for SVN revision 151720 is now obsolete in the current beta release
and is only needed for the stable version. So let's hope that >= 22.0.1229.91
will get stable soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
SVN revision 151720 breaks the build with system zlib, see:
http://src.chromium.org/viewvc/chrome?view=rev&revision=151720
The issue here is, that r151720 introduces changes directly in zlib, which
aren't upstream and unfortunately there is no more information stating the exact
reasons for this change, as all references to it are not publicly available:
http://crbug.com/139744https://chromiumcodereview.appspot.com/10837057
So for the moment, we're going to add a patch, which applies to v22 and higher,
which essentially reverts r151720, until either more information on the issue is
available or it is resolved upstream.
As someone has already reported the issue, we just need to track the following
issue:
http://crbug.com/143623
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This enables legacy seccomp sandbox by default even on chromium 22, because the
BPF sandbox is still work in progress, please see:
http://crbug.com/139872http://crbug.com/130662
Because the BPF seccomp sandbox is used in case the legacy seccomp mode
initialization fails, we might need to patch this again, as soon as the BPF
sandbox is fully implemented to fall back to legacy seccomp and use BPF by
default.
We now have two patches for "default to seccomp" - one for Chromium 21 and one
for 22 or higher.
The patch doesn't apply in version 22 and newer, because mode 1 sandboxes are
connsidered "legacy" (well, apart from the fact that I'd personally prefer BPF
anyway), for reasons I wasn't able to find, yet. But let's proceed on BPF
integration and thus gain more insight on the exact reasons.
Hurray! This is the first time chromium is working with NSS _and_ is able to
verify certificates using the root certificates built in into NSS.
Optimally it would use certs from OPENSSL_X509_CERT_FILE, but at least it's
working, so let's add that at some later point.
This caused HTML5 video to not work because this shared library is loaded at
runtime.
Unfortunately we can't use system ffmpeg yet, because upgrading would break
builds of other packages, and it would result in a copy of ffmpeg laying around
aswell, so we can defer this until we have fixed ffmpeg.
Thanks to @bluescreen303 for the bug report.
Always did this manually by putting -j8 into make flags, which i didn't commit,
as it obviously doesn't make sense to hardcode. However, this flag makes more
sense and obviously we need to avoid overriding buildPhase.
Which is enabled by default if neither pulseaudio or chromium.pulseaudio is
explicitly set. The reason is that chromium falls back to ALSA in case no
pulseaudio is available.
In addition it was necessary to patch media.gyp to ignore the array-out-of-
bounds warning.
This makes it easier to remember, as so far the naming wasn't quite consistent,
sometimes "use*", sometimes "enable*". So in using just use the feature name
itself, it should be pretty clear.
These libraries are heavily patched by the chromium project itself, so let's use
the bundled versions as those won't build anyway and also don't break functional
purity.
We also need to patch the compilation process, so it allows deprecated
declarations when building support for the cups backend. In addition, we also
need to add libgcrypt to dependencies as it's needed by the cups implementation.
This also separates gcrypt and gconf from the basic dependencies.
Unfortunately we cannot get rid of dbus_glib altogether, but maybe we want to
work on a patch to get rid of it? On the other hand it seems to be a TODO of the
chromium project itself, so let's wait and see.
Currently building fails with NSS, so we're using OpenSSL by default. And that's
why we want to make this configurable so if we manage to fix that build failure,
we could switch to using NSS by default.
This is mainly because of the patch to use OPENSSL_X509_CERT_FILE as a way to
specify the CA bundle. A browser which isn't able to verify SSL certificates
might be somewhat useless.
This is to make it more consistent with the naming of the package file and also
consistent with the build, as we're not using the Google branded version.
In addition the derivation attribute set now has a packageName value which can
be used to easily switch the binary names and paths, just in case we want to
switch to using "chrome" (or something entirely different) again.
There are still some libraries left, which we either need to patch or provide
more recent versions. Plus we're going to use openssl, as libnss doesn't want to
do proper SSL (let's debug this later).
If useSELinux is not set, enable seccomp mode by default and avoid building the
SUID helper sandbox at all. This involves a small patch which causes the
commandline arguments to be swapped: --disable-seccomp-sandbox to disable it,
while the option is active by default.
