Main menu:


Please consider a small donation:



Or you can donate bitcoin:


Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank


FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.


Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 425 other subscribers

My Favourites



April 2019
« Mar    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current



Chromium 49 packages address security issues; no more 32-bit binary plugins

chromium_iconChromium 49 was announced on the Google Chrome Releases blog. I needed some time to compile package for my ‘ktown’ repository containing the KDE Plasma 5 environment. In fact it took more time than anticipated because I had upgraded my QEMU from 1.2.0 to 2.5.0 and that had unepected side effects: it severely affected the performance of the host server (running Slackware64 13.37 and a kernel) and decreased the Virtual Machine speed to almost half. And when the VM froze while I was compiling chromium in it, I had enough. I reverted to QEMU 1.2.0 and all is well again.

Anyway, the new chromium 49.0.2623.75 release addresses a couple of security issues – some of these have a CVE number:

  • [$8000][560011] High CVE-2016-1630: Same-origin bypass in Blink. Credit to Mariusz Mlynski.
  • [$7500][569496] High CVE-2016-1631: Same-origin bypass in Pepper Plugin. Credit to Mariusz Mlynski.
  • [$5000][549986] High CVE-2016-1632: Bad cast in Extensions. Credit to anonymous.
  • [$3000][572537] High CVE-2016-1633: Use-after-free in Blink. Credit to cloudfuzzer.
  • [$3000][559292] High CVE-2016-1634: Use-after-free in Blink. Credit to cloudfuzzer.
  • [$2000][585268] High CVE-2016-1635: Use-after-free in Blink. Credit to Rob Wu.
  • [$2000][584155] High CVE-2016-1636: SRI Validation Bypass. Credit to Ryan Lester and Bryant Zadegan.
  • [$500][560291] High CVE-2015-8126: Out-of-bounds access in libpng. Credit to joerg.bornemann.
  • [$2000][555544] Medium CVE-2016-1637: Information Leak in Skia. Credit to Keve Nagy.
  • [$1000][585282] Medium CVE-2016-1638: WebAPI Bypass. Credit to Rob Wu.
  • [$1000][572224] Medium CVE-2016-1639: Use-after-free in WebRTC. Credit to Khalil Zhani.
  • [$1000][550047] Medium CVE-2016-1640: Origin confusion in Extensions UI. Credit to Luan Herrera.
  • [$500][583718] Medium CVE-2016-1641: Use-after-free in Favicon. Credit to Atte Kettunen of OUSPG.
  • [591402] CVE-2016-1642: Various fixes from internal audits, fuzzing and other initiatives.

It is advised to upgrade to this version of Chromium.

Please note that Google has stopped providing 32-bit versions of Chrome for Linux. This means that I will no longer be able to supply 32-bit plugins for Pepper Flash and for Widevine CDM support. The 32-bit plugins currently in my repository are taken from the Chrome 48 RPM and they will probably just keep functioning for a while. However I have no idea when they break, and particularly the Pepper Flash plugin will age pretty fast, considering the fact that Adobe releases security updates for Flash almost every month. YMMV.

Get my chromium packages in one of the usual locations:

The widevine and pepperflash plugin packagess for chromium can be found in the same repository.

Have fun! Eric


Comment from Mike Langdon
Posted: March 7, 2016 at 13:55

Hi Eric,
I upgraded this morning, and Chromium actually reverted to 37xxx from 13.37. That was weird. I had to manually upgrade sbbdeps because of an md5sum error. I am using the UK mirror. I do run -current.

Comment from BrianA_MN
Posted: March 7, 2016 at 16:26

Eric, Thanks for these updates to chromium. Sorry to hear you have had a problem with QEMU 2.5.0.

Comment from Thomas Morper
Posted: March 7, 2016 at 21:29

It’s just a guess, but I think I remember one QEMU upgrade where the names of the qemu executables changed, resulting in my VMs accidentally starting in some sort of software emulation mode (i.e. no KVM) after the upgrade, which made everything *very* slow. Explicitly running “qemu-system-x86_64” and adding “–enable-kvm” (is it needed?) fixed that.

Comment from alienbob
Posted: March 7, 2016 at 22:31

Yes, “–enable-kvm -machine type=pc,accel=kvm” was required to get it back up to speed, but the strain on the host was unacceptable even when the VM was running in idle mode. I assume this is because the newer QEMU releases are not written for the KVM in this old 2.6 kernel but are exploiting the capabilities of the new 4.x kernels.
The VM itself had barely half the performance of my old qemu-1.2.0 instances, so the choice to revert was an easy one.

Comment from Ricardo J. Barberis
Posted: March 7, 2016 at 22:38

Eric, Re: qemu, I actually have qemu-kvm-1.2.0-x86_64-1alien and qemu-2.3.0-x86_64-1sl installed.

I believe I reinstalled you package because of the same problem (Slack 14.1 64 bits here), should remove qemu-2.3.0 and reinstall you package to make sure I only use bits from yours and not slacky’s.

Are you using qemu direclty or through libvirt?

I’m using libvirt (from SBo) and in my VMs I have:


I have a vacation coming and I’m hoping to fiddle with this again, I’ll report back my findings if I can make it work with libvirt.

Oh, and thanks for the new Chromium 🙂


Comment from Ricardo J. Barberis
Posted: March 7, 2016 at 22:39

Ah, older kernel migh be the problem, yes.

Comment from Deny Dias
Posted: March 8, 2016 at 00:52

Hi there!

It’s just me or this new chromiun version doesn’t respect the mouse scroll direction anymore?

It doesn’t matter what the system wide setting says (regular/inverted), it always scroll regular.

All other software (incl. firefox) respect that scroll direction. Just chromiun is off.

This was not the case with version 48.

Comment from Deny Dias
Posted: March 8, 2016 at 00:58

Oh! It’s a bug (or, as always, a feature according to Google)!

Comment from Deny Dias
Posted: March 8, 2016 at 04:46

For those facing regular scrolling after chromiun 49, this have fixed it to me:

In that page, all other methods before this one have failed.

It’s a per user setting (the post is wrong about the system wide part). Luckily, it’s consistent across all applications if you remember to disable any inverted scroll setting in your DE.

Comment from alienbob
Posted: March 8, 2016 at 12:39

Google enabled “smooth scrolling” by default in Chromum 49.
To disable this if you do not like the smooth scrolling or because you re-defined the scroll features in X.Org, open the URI chrome://flags/#disable-smooth-scrolling in your Chrome or Chromium browser (works across all platforms).

Comment from Drakeo
Posted: March 8, 2016 at 23:32

Hi Eric “chromium current” seems there may be something wrong with your build not detecting cubeutil. if flash it will read chromium and or no sound in pavucontrol because no playback.
I do not have this problem with my CEF3 builds of the chrome 49 . CEF you actually build chromium then build the embedded part. Going to rebuild yours and look at your config.

Comment from alienbob
Posted: March 8, 2016 at 23:49

Drakeo – don’t even know what cubeutil is, how does it relate to Chromium?
Also your sentence “if flash it will read chromium and or no sound in pavucontrol because no playback” does not make sense to me.

Pingback from Links 8/3/2016: Future Kodi Veraions, Solus 1.1 | Techrights
Posted: March 9, 2016 at 01:53

[…] Chromium 49 packages address security issues; no more 32-bit binary plugins […]

Comment from Drakeo
Posted: March 9, 2016 at 01:54

It is stuck at linking so I am unable to finish the build.
I am unable to get any feed back. but after 30 minute wait for it to link there is an issue.
I will get back with you I will figure it out turn up the Verbose a tad.

Comment from Drakeo
Posted: March 9, 2016 at 02:11

OK figured it out Was testing MIXXX builds left a .asoundrc
file down. Everything works great.
About the linking I will look into that that is after today’s latest update.
I am sure it is on my end.

Comment from alienbob
Posted: March 9, 2016 at 10:52

The final linking stage of chromium can take a long while and especially it takes a _lot_ of RAM. If you get errors during the linking stage, consider adding more swap.

Comment from Eduardo
Posted: March 9, 2016 at 13:53

Thank you Eric! So far it’s working good.

Comment from inman
Posted: March 9, 2016 at 14:17

well done as always, but you may want to update the development version too, since it is now quite older than the stable version now. tanx, and cheers

Comment from alienbob
Posted: March 9, 2016 at 14:54

Hey, it’s the development version, so I added it only for people to play with; it should not be used in production anyway.
You can build a new version using my SlackBuild but currently it is not high on my own priority list.

Write a comment