Overview of the updated versions:
stable: 48.0.2564.116 -> 49.0.2623.75
beta: 49.0.2623.63 -> 49.0.2623.75
dev: 50.0.2657.0 -> 50.0.2661.11
Stable and beta are now in par because of the release of a major stable
update.
The release addresses 26 security vulnerabilities, the following with an
assigned CVE:
* CVE-2016-1630: Same-origin bypass in Blink. Credit to Mariusz
Mlynski.
* CVE-2016-1631: Same-origin bypass in Pepper Plugin. Credit to Mariusz
Mlynski.
* CVE-2016-1632: Bad cast in Extensions. Credit to anonymous.
* CVE-2016-1633: Use-after-free in Blink. Credit to cloudfuzzer.
* CVE-2016-1634: Use-after-free in Blink. Credit to cloudfuzzer.
* CVE-2016-1635: Use-after-free in Blink. Credit to Rob Wu.
* CVE-2016-1636: SRI Validation Bypass. Credit to Ryan Lester and
Bryant Zadegan.
* CVE-2015-8126: Out-of-bounds access in libpng. Credit to
joerg.bornemann.
* CVE-2016-1637: Information Leak in Skia. Credit to Keve Nagy.
* CVE-2016-1638: WebAPI Bypass. Credit to Rob Wu.
* CVE-2016-1639: Use-after-free in WebRTC. Credit to Khalil Zhani.
* CVE-2016-1640: Origin confusion in Extensions UI. Credit to Luan
Herrera.
* CVE-2016-1641: Use-after-free in Favicon. Credit to Atte Kettunen of
OUSPG.
The full announcement which also includes the link to the bug tracker
can be found here:
http://googlechromereleases.blogspot.de/2016/03/stable-channel-update.html
Also, the 32bit Chrome package needed for the Flash and Widevine plugins
doesn't exist anymore, because Google has dropped support for 32bit
distros, see here for the announcement:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/FoE6sL-p6oU
On our end, we need to fix the patch for the plugin paths to work for
the latest dev channel. The change is very minor, because the
nix_plugin_paths_46.patch only doesn't apply because of an iOS-related
ifdef.
Built and tested on my Hydra at:
https://headcounter.org/hydra/eval/311511
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #13665
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
Comparing the current version with the version in sources list and
accidentally swapping the version arguments isn't going to get very far
because every new version that will come up will then be treated as "we
already have that version".
So we're now using versionOlder and also a check whether the version is
the *same* as the one in sources.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
No changes in functionality, but to make future source updates a bit
easier on the eyes when viewing the diff.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The update.sh shell script now is only a call to nix-build, which does
all the hard work of updating the Chromium source channels and the
plugins. It results in a store path with the new sources.nix that
replaces the already existing sources.nix.
Along the way, this has led to a quite massive workaround, which abuses
MD5 collisions to detect whether an URL is existing, because something
like builtins.tryEval (builtins.fetchurl url) unfortunately doesn't
work. Further explanations and implementation details are documented in
the actual implementation.
The drawback of this is that we don't have nice status messages anymore,
but on the upside we have a more robust generation of the sources.nix
file, which now also should work properly on missing upstream
sources/binaries.
This also makes it much easier to implement fetching non-GNU/Linux
versions of Chromium and we have all values from omahaproxy available as
an attribute set (see the csv2nix and channels attributes in the update
attribute).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As stated in the parent commit, the 32bit Chrome package is not
available upstream, so let's at least provide the SHA256 hash for the
64bit package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Until now, if we have a failure to fetch either the 32bit Debian package
or the 64bit Debian package, neither of these will be put into
sources.nix.
Unfortunately the beta/dev channels do not have a 32bit Debian package,
so even though there is a 64bit Debian package available we don't get
plugins *at* *all*.
This also introduces a nicer error message rather than just failing with
an assertion in fetchurl because we did not provide url/urls.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
From the debian security mailing list:
Several vulnerabilities have been discovered in the chromium web browser.
CVE-2016-1622
It was discovered that a maliciously crafted extension could bypass
the Same Origin Policy.
CVE-2016-1623
Mariusz Mlynski discovered a way to bypass the Same Origin Policy.
CVE-2016-1624
lukezli discovered a buffer overflow issue in the Brotli library.
CVE-2016-1625
Jann Horn discovered a way to cause the Chrome Instant feature to
navigate to unintended destinations.
CVE-2016-1626
An out-of-bounds read issue was discovered in the openjpeg library.
CVE-2016-1627
It was discovered that the Developer Tools did not validate URLs.
CVE-2016-1628
An out-of-bounds read issue was discovered in the pdfium library.
CVE-2016-1629
A way to bypass the Same Origin Policy was discovered in Blink/WebKit,
along with a way to escape the chromium sandbox.
Fixes: #12840
Related to: 61042a561042a5 changes the replaced token from $something to @something@. This
commit repeats that change in one additional location used by the
WideVine plugin
There is already a pull request from @colemickens, who has just reversed
the variable references $flash and $flashVersion but the fix is kinda
fragile as he points out himself in #12713.
The reason the wrong substition was made is that both variables begin
with the same name and we do a simple replace instead of a more
complicated one using builtins.match.
So staying simple but to still not raising issues with other variables
that begin with the same name I'm now using @var@ instead, like we use
in substituteAll and other substituters (like the ones in CMake or
autotools) deal with it.
Note that I'm not using $var$ here to make sure it doesn't get confused
with real shell variables.
So with this fix in place, the wrapper now has the following flags:
--ppapi-flash-path=/nix/store/.../lib/libpepflashplayer.so
--ppapi-flash-version=20.0.0.294
Previously we had (#12710):
--ppapi-flash-path=/nix/store/.../lib/libpepflashplayer.so
--ppapi-flash-version=/nix/store/...-binary-plugins-flashVersion
Thanks to @colemickens for reporting and putting up a pull request.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #12710
Fixes: #12713
This reverts commit f7af2272a2.
We're going to fix #12710 properly by reintroducing 38c77bb and fixing
the shell variable substitution.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Fixes CVE-2016-1612 CVE-2016-1613 CVE-2016-1614 CVE-2016-1615
CVE-2016-1616 CVE-2016-1617 CVE-2016-1618 CVE-2016-1619 CVE-2016-1620.
- Moves chromium stable and beta channels up one version major.
vcunat made dev channel stay for now, as it wouldn't download otherwise.
This is most of PR #12717.
This package is deprecated and superseeded by links2 which also provides the
links binary this maintaining backwards-compatibility.
Debian removed links back in 2008:
https://packages.qa.debian.org/l/links.html
Fixes #12623.
Working on Chromium really drives me nuts due to its build time, also I
really don't have quite a lot of time these days to properly maintain it
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has been introduced by me in 690a845 and discovered by @vcunat in
his comment over at:
690a845de9 (commitcomment-14209868)
It's really a bit ugly to have builds running during evaluation, but
back when I made that commit the reason was to avoid having to shell
quote the hell out of it (see the comment in mkPluginInfo for the
reason).
Now we propagate plugin flags and environment variables as a list of
arguments in a plain file that's appended verbatim to makeWrapper, so
it shouldn't do any builds anymore during instantiation.
I have tested this with both just WideVine and just Flash enabled as
well as both in combination and none of the plugins and the output seems
correct. However I didn't test to run Chromium with the new
implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Vladimír Čunát <vcunat@gmail.com>
I'm not certain about this, so I'm trying for firefox only.
Rationale: it might be confusing to see two firefox-${version} instances
in logs or paths, so I wanted to differentiate them.
- I chose to keep `browser-unwrapped` attributes so that it's much
easier to override parameters for the browser (through `packageOverrides`).
- Aliases `browserWrapper` are retained for now, as usual.
The official repository has last been updated in 2013,
meanwhile there are a lot of issues like non-existant
certificate verification. The debian repository is actively
maintained and already includes most of our custom patches,
so we use it instead.
Fixes #12257, closes #12259.
vcunat appended commit date to version.
- I don't think that amount of code belonged into all-packages.nix.
- Now the default name of the wrapped package is identical
with the command that runs the browser.
- Other defaults were changed according to how the wrapper is
(almost always) used.
- `meta` is improved: mostly inherited with priority above
the unwrapped package.
http://hydra.nixos.org/eval/1234895
The mass errors on Hydra seem transient; I verified ghc on i686-linux.
Only darwin jobs are queued ATM. There's a libpng security update
included in this merge, so I don't want to wait too long.
It is a little weird that chromium has chromium, chromiumBeta,
chromiumDev but this one is google-chrome, google-chrome-beta,
google-chrome-dev. Not quite sure what the best resolution is, if any.
Built and run Beta and Stable locally. Dev is surrently superseded by Stable so
it doesn't matter much.
- Dev: 47.0.2508.0 -> 48.0.2564.22
- Beta: 46.0.2490.64 -> 48.0.2564.23
- Stable: 45.0.2454.101 -> 47.0.2526.73
Changed the SSL dependencies to the supported configuration on Linux (according
to Torne @Freenode/#chromium-support).
- NSS is a dependency since it is used to access the ceritiface store.
- Dropped system OpenSSL support, the bundled BoringSSL is used.
This probably fixes issue #10555. Note that without this adjustment the build
fails even.
Dropped uneeded old patches.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
As suggested the Google Chrome .deb file that is used for Chromium's plugins is reused.
vcunat removed lots of newlines, as the style was diverging from the
majority far too much (IHHO).
Close #10444, fixes #8749.
For some reason it's more involved than just setting gyp configuration,
we also have to set some definitions in widevine_cdm_version.h according
to the comments left in the file. Arch Linux does this already and so we
should probably just use the patch they created while getting Netflix to
work:
https://code.google.com/p/chromium/issues/detail?id=429452#c16
- systemd puts all into one output now (except for man),
because I wasn't able to fix all systemd/udev refernces
for NixOS to work well
- libudev is now by default *copied* into another path,
which is what most packages will use as build input :-)
- pkgs.udev = [ libudev.out libudev.dev ]; because there are too many
references that just put `udev` into build inputs (to rewrite them all),
also this made "${udev}/foo" fail at *evaluation* time
so it's easier to catch and change to something more specific
Upstream changes to the build system required adjusting many packages'
dependencies. On the Nixpkgs side, we no longer propagate the dependency
on cmake (to reduce closure size), so downstream dependencies had to be
adjusted for most packages that depend on kdelibs.
The patch only applies for Firefox versions between 37.0 and 40.1.
Because we're on version 41.0 the changes are already included upstream
and thus the patch doesn't apply and is even unnecessary.
As for version 38.3 for ESR, the patch doesn't apply as well if compiled
with enableGTK3. Of course, this is a bit unfortunate but I don't have
the time right now to properly rebase the patch on 38.3.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: devhell <"^"@regexmail.net>
It's another attempt to fix chromium builds.
See http://hydra.nixos.org/build/26086977/nixlog/4/raw
Unpacking sources is actually taking more than 2h so build fails.
Instead, rather build it remotely and then copy over the output as
we don't have limits for download time.
See 089bdce621 for reference
cc @aszlig
(cherry picked from commit cef54e7d67)
Signed-off-by: Domen Kožar <domen@dev.si>
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
Although I couldn't test this because I'm not using a DE, nobody else
than the one submitting the pull request has commented on this. So if it
should break the icon for other people, nobody would probably start an
assassination because of this and the commit can be easily reverted if
it should break the icon.
wkennington@f6c1004 switched Firefox to GStreamer 1.0 by changing its
buildInput *only*, but that is not enough. We need to fix Firefox
wrappers by changing their buildInputs and set GST_PLUGIN_SYSTEM_PATH_1_0
instead of GST_PLUGIN_SYSTEM_PATH.
With above changes playing H.264/MP4 media works in firefoxWrapper and
conkerorWrapper as tested with
http://www.quirksmode.org/html5/tests/video.html and
https://soundcloud.com/immclovin33/synthetix-sundays-53-with-marko-maric-19715
It should help with peti#9247
Reviewed-by: kmicu <kmicu@protonmail.ch>
Tested-by: kmicu <kmicu@protonmail.ch>
Overview of the updated versions:
beta: 45.0.2454.15 -> 45.0.2454.26
dev: 45.0.2454.15 -> 46.0.2471.2
Changes for getting beta and dev channel to build:
* The reference for chrome::FILE_FLASH_PLUGIN doesn't exist anymore in
version 46, because it has been dropped upstream, see the following
review URL:
https://codereview.chromium.org/1255943002
We set the PPAPI Flash path using a command line flag anyway, so it
doesn't hurt us if we don't patch that path (which was an old
artifact from the NSAPI->PPAPI conversion anyway).
Changes for the dev channel only:
* It seems that in the SCM, chrome/test/data/webui/ contains a lot of
files, however they are missing in the tarball.
This has been reported upstream at: https://crbug.com/515917
Our fix is to just not include webui/i18n_process_css_test.html at
all, to avoid the configure (gyp) phase to fail, because we're not
building tests anyway.
All channels built and tested by my Hydra instance at:
https://headcounter.org/hydra/eval/218978
Test reports:
x86: https://headcounter.org/hydra/build/723341/download/1/log.html
x86_64: https://headcounter.org/hydra/build/723342/download/1/log.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Use system libpng with apng support.
Use the system icu which works fine in newer firefox builds.
Use jemalloc to speed up memory allocations and reduce fragmentation.
This reverts commit cd52c04456 and
others.
Managing certificates (including revoking certificates and adding
custom certificates) becomes extremely painful if every package in the
system potentially depends on a different copy of cacert. Also, it
makes updating cacert rather expensive.
The only mirror left which still has the .deb for 44.0.2403.89 is
http://mirror.pcbeta.com/, but that one doesn't seem to be reachable
from certain contries.
And according to @CestDiego, it doesn't seem to be reachable from within
the US.
Closes #9021, thanks to @CestDiego for reporting.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Diego Berrocal <cestdiego@gmail.com>
Tested-by: Diego Berrocal <cestdiego@gmail.com>
Overview of the updated versions:
stable: 43.0.2357.125 -> 43.0.2357.130
beta: 44.0.2403.52 -> 44.0.2403.61
For the beta channel the following changes were necessary:
* Drop all patches which were added in c290595 because they apply to
44.0.2403.52 only. The shipped version of Blink was older than the
one used for Chromium itself and thus contained just the
cherry-picked patches from upstream Blink.
* The ffmpegsumo library is now statically linked the same way as in
the dev version, so let's not try to put it into the output store
path.
All channels were built successfully on my Hydra at:
https://headcounter.org/hydra/eval/187176
VM tests did also pass and can be found at:
x86: https://headcounter.org/hydra/build/707636
x86_64: https://headcounter.org/hydra/build/707637
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just silencing the error will not prevent Chromium from trying to start
up the SUID sandbox anyway, thus flooding stderr with:
LaunchProcess: failed to execvp:
After digging a bit in the source code I found out that the SUID sandbox
binary is indeed used, but only for setting oom_score_adj within the
user namespace (as "root"). So let's build the sandbox binary and of
course don't set setuid bit.
These annoying error messages were originally introduced by 0aad4b7 and
I'm deeply sorry for annoying you guys out there with them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since 0aad4b7, we no longer need to have an external sandbox binary,
because the upstream implementation of the user namespace sandbox no
longer needs an external sandbox binary.
In our implementation of the user namespace sandbox, we (ab)used the
setuid sandbox to run non-setuid and set up user namespaces instead.
Because our implementation is no longer needed, we can safely drop the
external binary entirely.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There has been some recent news about that component extension on hacker
news:
https://news.ycombinator.com/item?id=9724409
Even though on our side it won't work, because we don't have NaCl
enabled by default or even working (I honestly haven't tested if it even
builds if enabled), we might get to the point where we can build with
NaCl enabled.
But until and even after that day, we want to have explicit control on
whether this extension is enabled.
Please also have a look at these two issues explaining the details
(about component extensions and the hotwording extension in particular):
https://crbug.com/491435https://crbug.com/500922
Fixes issue #8358.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There was the usual crashing and a few icons missing.
@lethalman: I think it's best to start putting $XDG_ICON_DIRS into suffix
instead of prefix (as here), so user-installed icons take precedence.
/cc #7743.
This also merges pull request #8290 plus a few other fixes from
@ambrop72 and me.
The summary of changes is:
* Update all channels to latest upstream.
* Update GYP package and drop gyp_svn1977.
* Remove ICU from buildInputs to prevent build failure.
* Switch back to using --depth . to GYP instead of patching in the
absolute store paths.
* Don't symlink source code anymore, which might introduce a
regression on high I/O load on Hydra. As this is only a temporary
build fix, let's cross fingers and hope we don't hit it. See
c92dbffeac for an explanation.
* Use HTTPS for the bucket URL.
* Fix nix_plugin_paths patch for version 44 and higher.
Tested at: https://headcounter.org/hydra/eval/169134
The pepper effects plugin has been removed and migrated to NaCl, so I'm
just dropping the hunk of that patch.
Upstream reviow URL: https://codereview.chromium.org/1085393003
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Changes included:
- Update versions.
- Use gyp package not gyp_svn1977.
- Remove icu from buildInputs, since this causes a build error due to inferference with use_system_icu=false.
- Remove the hack that inserts the absolute path into gyp files, and pass `--depth .` to gyp. This resolves the `third_party/angle` gyp error.
- Do a normal copy of the source code not a symlink copy. This resolves some link error where the symlinks interfere with relative paths (seems like because gyp resolves symlinks first). Note, this used to be worked around with the absolute path insertion hack.
- Change the bucketURL in update.nix to https (for more secure updates).
