Google updated the stable branch of the Chromium browser to a new major version number: “51”. An overview of the changes since the previous “50” release are found in Google’s git. Updated packages for Slackware 14.1 and -current are now available from my repository, for the download URLs see below.
The announcement on the Google Chrome Releases blog mentions a list of vulnerabilities that were addressed with this release. Here are the ones that got a CVE rating… it sure pays off to be a security researcher and find Google Chrome vulnerabilities:
- [$7500][590118] High CVE-2016-1672: Cross-origin bypass in extension bindings. Credit to Mariusz Mlynski.
- [$7500][597532] High CVE-2016-1673: Cross-origin bypass in Blink. Credit to Mariusz Mlynski.
- [$7500][598165] High CVE-2016-1674: Cross-origin bypass in extensions. Credit to Mariusz Mlynski.
- [$7500][600182] High CVE-2016-1675: Cross-origin bypass in Blink. Credit to Mariusz Mlynski.
- [$7500][604901] High CVE-2016-1676: Cross-origin bypass in extension bindings. Credit to Rob Wu.
- [$4000][602970] Medium CVE-2016-1677: Type confusion in V8. Credit to Guang Gong of Qihoo 360.
- [$3500][595259] High CVE-2016-1678: Heap overflow in V8. Credit to Christian Holler.
- [$3500][606390] High CVE-2016-1679: Heap use-after-free in V8 bindings. Credit to Rob Wu.
- [$3000][589848] High CVE-2016-1680: Heap use-after-free in Skia. Credit to Atte Kettunen of OUSPG.
- [$3000][613160] High CVE-2016-1681: Heap overflow in PDFium. Credit to Aleksandar Nikolic of Cisco Talos.
- [$1000][579801] Medium CVE-2016-1682: CSP bypass for ServiceWorker. Credit to KingstonTime.
- [$1000][583156] Medium CVE-2016-1683: Out-of-bounds access in libxslt. Credit to Nicolas Gregoire.
- [$1000][583171] Medium CVE-2016-1684: Integer overflow in libxslt. Credit to Nicolas Gregoire.
- [$1000][601362] Medium CVE-2016-1685: Out-of-bounds read in PDFium. Credit to Ke Liu of Tencent’s Xuanwu LAB.
- [$1000][603518] Medium CVE-2016-1686: Out-of-bounds read in PDFium. Credit to Ke Liu of Tencent’s Xuanwu LAB.
- [$1000][603748] Medium CVE-2016-1687: Information leak in extensions. Credit to Rob Wu.
- [$1000][604897] Medium CVE-2016-1688: Out-of-bounds read in V8. Credit to Max Korenko.
- [$1000][606185] Medium CVE-2016-1689: Heap buffer overflow in media. Credit to Atte Kettunen of OUSPG.
- [$1000][608100] Medium CVE-2016-1690: Heap use-after-free in Autofill. Credit to Rob Wu.
- [$500][597926] Low CVE-2016-1691: Heap buffer-overflow in Skia. Credit to Atte Kettunen of OUSPG.
- [$500][598077] Low CVE-2016-1692: Limited cross-origin bypass in ServiceWorker. Credit to Til Jasper Ullrich.
- [$500][598752] Low CVE-2016-1693: HTTP Download of Software Removal Tool. Credit to Khalil Zhani.
- [$500][603682] Low CVE-2016-1694: HPKP pins removed on cache clearance. Credit to Ryan Lester and Bryant Zadegan
-
[614767] CVE-2016-1695: Various fixes from internal audits, fuzzing and other initiatives.
As always, it is strongly advised to upgrade to this new version of Chromium. Get my chromium packages in one of the usual locations:
- http://slackware.com/~alien/slackbuilds/ (primary server)
- http://bear.alienbase.nl/mirrors/people/alien/slackbuilds/ (my own fast mirror)
- http://slackware.uk/people/alien/slackbuilds/ (UK mirror – fast & preferred, also has rsync access)
- http://alien.slackbook.org/slackbuilds/ (US mirror)
The widevine and pepperflash plugin packagess for chromium can be found in the same repository. The 64bit version of the Widevine plugin was updated with new libraries extracted from the official Google Chrome for Linux; the new Chrome does not contain a newer PepperFlash than what I already have in my repository.
Remember, even though I can still provide a 32bit Chromium browser, Google has ceased providing a 32bit version of their own Chrome browser – which means, no more updates to the 32bit PepperFlash and Widevine plugins.
Have fun! Eric
Thanks Eric, work fine 😉
Thank you Eric! Everything is working fine here.
Thank you Eric!
Even though I have a 1080p display and 100% magnification, I’m seeing some blurry text. Foremost amongst these is the Faceboot chat popups while browsing the main Facebook site. I suspect there is a hidden config parameter that was altered or is new and which is responsible for this.
If you search the Internet for “chromium blurry text linux” you’ll see that this affects a long list of previous Chrome/Chromium releases, and not just on Linux but Windows too. There are some documented mitigations but they might have side effects.
The interface in chromium browser be fierce wrapped in black. I like it 🙂
Eric, thanks for the suggestions. Oddly enough, now the talk boxes appear clearer without any intervention from my part.
Hi Eric,
suddenly found out my chromium doesn’t have HW acceleration:
chrome://gpu/ tab says “Software only, hardware acceleration unavailable” on almost all positions.
Below on the same tab, I think the explanation:
“Problems Detected
GPU process was unable to boot: GPU access is disabled in chrome://settings.
Disabled Features: all”
Chrome doesn’t have this problem on the same system
bam if you find out what’s needed to enable GPU hardware acceleration let me know so that I can implement it.
Eric, do you have hardware acceleration unavailable also, or it is my specific situation?
I’m getting a shared object file not found error, doesn’t seem to be a major issue though
“libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva error: dlopen of /usr/lib64/dri/r600_drv_video.so failed: libLLVM-3.6.so: cannot open shared object file: No such file or directory”
The file “/usr/lib64/dri/r600_drv_video.so” is probably a symlink to “/usr/lib64/dri/vdpau_drv_video.so”? It is a VAAPI driver file for AMD/Ati graphics cards which you installed at some point (it is not part of Slackware nor of my own repository as far as I know).
And this driver was compiled on Slackware-current somewhere in 2015. Later in 2015, the llvm package in Slackware-current was upgraded to 3.7.0 and that broke the link in this file of yours.
Recompile the package that installed that file. It should fix GPU-assisted hardware acceleration in your video output.
Doh, it is in fact an old untracked file, most likely from fglrx, that I stopped using last year.
Hi Eric,
still can’t get HW acceleration on my setup.
What is the best place to file a bug?
Is there a bug-tracker, or anything?
For now, only other place I can see to report problem is LinuxQuestions, but I’m not sure it’s the best place also..
I do not have a bug tracker. I would stop having a life if I had to look at all the bugs people find and want me to fix for them.
It is your bug, try to find what’s happening and write a post on LQ.org with as much information as you can get. Hopefully someone will respond.
Ok, but I even was not sure it’s my bug: it could be disabled at build time by whatever reason, that is why I asking here.. Sorry if I disturb you. Will search help on LQ
bam, your post on LQ (http://www.linuxquestions.org/questions/slackware-14/alien-bob%27s-chromium-no-hw-acceleration-4175585797/) shows that this was after all not a bug, rather a configuration issue.
Glad it was solved with the help of the friendly audience in the Slackware forum.
Hello Bob. In the last 2 years I\’ve been using your slackbuilds perfectly and with no issues but now I have found a problem.
I was able to build the Chromium version 53.0.2785 for slackware 14.2 from slackbuilds.org and I was using it just fine and recently I decided to upgrade to
your more recent version 61. I followed all the prerrequisites for my slackware-32 bit:
– rebuilt libelf with -D_FILE_OFFSET_BITS=64 added to CFLAGS
– libtinfo
– ninja 1.8.2
– nodejs 4.2.4
While building it, it crashed with the following error message (see at the bottom)
I modified your slackbuild and replaced this line:
export -n CFLAGS=\”$SLKCFLAGS -Wno-unused-local-typedefs\”
with:
#export -n CFLAGS=\”$SLKCFLAGS -Wno-unused-local-typedefs -std=c99\”
But I had the same error message as before. I also tried other combinations like -std=c11, -std=gnu11 or -std=gnu99, but always same error.
(C++ compiler shows no issues, only the C compiler at this point of the build)
I thought this could be a ninja related issue, but version 53 from slackbuilds also uses ninja/meson… so this is not the problem… so what is wrong then?
How can I force the compiler gcc 4.9.2 to use -std=gnu11 or -std=c99? I could see in some forums for other linux flavors that for this GCC version they pass
the flags directly to the gyp files, but is this valid with slackware? Do you have a patch or an idea for how to fix this issue? Maybe a c99 wrapper?
Error Message:
[5232/29213] CXX obj/third_party/angle/src/vulkan_support/vulkan_layer_utils/vk_layer_utils.o
[5233/29213] CC obj/third_party/angle/src/vulkan_support/vulkan_loader/extension_manual.o
FAILED: obj/third_party/angle/src/vulkan_support/vulkan_loader/extension_manual.o
gcc -MMD -MF obj/third_party/angle/src/vulkan_support/vulkan_loader/extension_manual.o.d -DV8_DEPRECATION_WARNINGS -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 (plus many many more flags)
../../third_party/vulkan-validation-layers/src/loader/extension_manual.c: In function \’terminator_EnumeratePhysicalDeviceGroupsKHX\’:
../../third_party/vulkan-validation-layers/src/loader/extension_manual.c:115:9: error: \’for\’ loop initial declarations are only allowed in C99 or C11 mode
for (uint32_t i = 0; i < copy_count; i++) {
^
../../third_party/vulkan-validation-layers/src/loader/extension_manual.c:115:9: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
../../third_party/vulkan-validation-layers/src/loader/extension_manual.c: In function \'setupLoaderTrampPhysDevGroups\':
../../third_party/vulkan-validation-layers/src/loader/extension_manual.c:236:5: error: \'for\' loop initial declarations are only allowed in C99 or C11 mode
for (uint32_t group = 0; group < total_count; group++) {
^
.
.
.
(many more errors asking for -std=c99 or alike)
.
.
.
[5238/29213] CXX obj/third_party/angle/src/vulkan_support/VkLayer_core_validation/core_validation.o
ninja: build stopped: subcommand failed.
Regards,
Xaparro, I built the chromium 61 package for Slackware 14.2 932bit ) with exactly the SlackBuild script you’ll find in my repository, and with a full instal of Slackware 14.2 refreshed with all the available patches.
The libelf of Slackware 14.2 already uses the “-D_FILE_OFFSET_BITS=64” so you do not need to recompile that. Other than that, you appear to have done the same as me. Do you have sufficient RAM?
Alienbob: I have 12 GB RAM (I think that’s enough) and my slackware version is current, sitting between 14.1 and 14.2 (from january 2016) plus other package.. the gcc version is 4.9.2… that’s why im suspecting of GCC… or maybe a missing library not letting me compile a program with a format suitable for c99… while checking on the debugs I never see the flag c99 or c11 passed to the compiler…maybe a missing c99 symlink? do you know another way to force the compiler to use c99?
Alienbob: I have 12 GB RAM and the slackware version is current, sitting between 14.1 and 14.2 (from january 2016) plus other packages I have upgraded over time. I dont have 14.2 as you do. GCC version is 4.9.2, that’s why im suspecting of GCC… or maybe a missing library not letting me compile a program with a format only suitable for c99… maybe a missing c99 symlink or wrapper? Do you know another way to force the compiler to use c99 or another flag injection point?
(forget about the first version of my answer, I dont know why it was published while I was double checking my response)
Well, your Slackware version is not “current” at all, if you stopped updating somewhere between 14.1 and 14.2. Perhaps that is what you should do first – get a stable 14.2.
Yes bob, I have seen in some forums from gentoo, archlinux, etc that the recommendation for people having the same issue is to either upgrade the GCC version or pass the switches to the compiler …. I installed 14.2 (GCC 5.3) in my second laptop and worked fine… but I dont understand why is not working with GCC 4.9.2…that’s the question lingering on the air… any idea?