Alien Pastures

My thoughts on Slackware, life and everything

Tag: chromium (Page 13 of 20)

Chromium 68 with updated Widevine plugin

August 4, 2018 / / 11 Comments

chromium_iconLast week, Chromium 68 was introduced to the “Stable Channel” with lots of bugs fixed, many of those being security fixes (42 in total). And a few days ago an update was released, so I decided to build Chromium 68 for Slackware.

NOTE: starting with Chromium 68, the browser will show a “Not secure” warning on all HTTP pages. Google announced this in a blog post published on February 8th on Google’s Chromium and Online Security blogs.

You’ll find 32bit as well as 64bit packages for Chromium 68.0.3440.84 in my package repository. They are available for both Slackware 14.2 and -current. I have also updated the Chromium Widevine plugin to version 1.4.9.1088. The older version refused to work with Chromium 68. Note that the Widevine plugin is available for 32bit just as for the 64bit browser, so even those running older computers (or those of you who are in need of a 32bit OS) can enjoy DRM movie playback.

For newcomers: Widevine is a Content Decryption Module (CDM) used by Netflix to stream video to your computer in a Chromium browser window. With my chromium and chromium-widevine-plugin packages you no longer need Chrome (or Firefox if you dislike that browser), to watch Netflix.

Also note (to the purists among you): even though support for Widevine CDM plugin has been built into my chromium package, that package is still built from Open Source software only. As long as you do not install the chromium-widevine-plugin package, your system will not be tainted by closed-source code.

Chromium packages: https://slackware.nl/people/alien/slackbuilds/chromium/ (rsync://slackware.nl/mirrors/people/alien/slackbuilds/chromium/)
Widevine packages: https://slackware.nl/people/alien/slackbuilds/chromium-widevine-plugin/ (rsync://slackware.nl/mirrors/people/alien/slackbuilds/chromium-widevine-plugin/)

July security updates: Chromium and Flash

July 25, 2018 / / 11 Comments

I have uploaded new packages for Chromium. The version 67.0.3396.99 was released a month ago but the source remained unavailable for a while and then I “went under” for a while. Now that I finally built and uploaded it, I noticed there’s a new version up today (68.0.3440.75) but I will wait a bit with that one and focus on Plasma5 next.

Get these chromium-67.0.3396.99 packages for Slackware 14.2 and -current overhere:

And then there’s the July security update for Adobe’s Flash Player plugins, which is already two weeks old – also released when I was indisposed.
The version 30.0.0.134 of the flashplayer-plugin (NPAPI plugin for Mozilla based browsers) and the chromium-pepperflash-plugin (PPAPI plugin for Chromium based browsers) is now available as a Slackware package in my repository.

Cheers, Eric

Security week

February 9, 2018 / / 9 Comments

This week and the last, I have pushed quite a few packages into my repository that are meant to enhance the safety of your Slackware computer. If you have not been hiding under a stone for the past couple of weeks, you will have read about the Spectre/Meltdown vulnerabilities that plague many CPUs. Mostly Intel CPU’s, but the less harmful variants are also affecting AMD and ARM CPU’s. The broader Linux community is working hard to mitigate the effects of these vulnerabilities, and new kernels have landed in Slackware that have been recompiled with patched compilers so that the vulnerabilities will be harder (or impossible) to exploit.

These patched GCC compilers in Slackware 14.2 and -current needed a multilib variant of course, so you will find those in my multilib repository. For Slackware 14.2 that’s a set of all-new gcc-5.5.0 packages, i.e. the latest gcc 5 release available. In Slackware-current it’s of course the latest gcc 7: version 7.3.0. These compilers support “-mindirect-branch=thunk-extern“, allowing full mitigation of Spectre v2 in the kernel (when CONFIG_RETPOLINE is used).

Then there were the monthly Flash security vulnerabilities, patched by Adobe in version 28.0.0.161 of the flashplayer-plugin (NPAPI plugin for Mozilla based browsers) and the chromium-pepperflash-plugin (PPAPI plugin for Chromium based browsers).  This one was particularly nasty because a 0-day exploit was used actively to gain full control of vulnerable computers (including Linux computers).

The update of Chromium to version 64.0.3282.140 fixed one security related bug, but the previous stable release (the first 64 version I packaged two weeks ago) actually plugged a series of serious vulnerabilities with CVE‘s assigned to them. So, time to upgrade!
And this latest Chromium package of mine has one additional feature: I enabled HEVC/H.265 video playback in the embedded ffmpeg engine. Try it out here: http://www.h265files.com/embed-h265-video.php and notice that most other browsers (except Microsoft Edge and Apple Safari) do not support this video codec. Unfortunately, the online HTML5 tester does not detect this HEVC playback capability.

Another browser’s security update: Pale Moon plugs two vulnerabilities with their 27.7.2 release. Updated package available in my repository of course.

 

And to end this series, I will soon upload a patched plasma-workspace-5.11.3 package for Slackware64 14.2, for those of you who are running my ‘ktown’ Plasma5 desktop.
A vulnerability was discovered, allowing arbitrary command execution in the removable device notifier.
This bug is already fixed in Plasma 5.12, so those who run the Plasma5 Desktop on Slackware-current only need to wait until tomorrow to get an all-new monthly set of packages among which Plasma 5.12. Watch this blog for the news!

Chromium 64 – and 32bit pain

January 29, 2018 / / 7 Comments

The new release of the Chromium sources gives us version 64 of Google’s browser. I have created Slackware packages for you, but that was not entirely trivial.
The Chromium compilation on my 32bit Slackware OS kept failing on the embedded ffmpeg. I am afraid the fact that some of the bigger distros are dropping 32bit variants starts showing and things are coming apart at the seams.
When you are a developer and there’s no 32bit release of your favorite OS, this makes it quite difficult to test the validity of code paths when you only compile and test your code on a 64bit platform. This is what’s happening with Google’s Chromium code and it will probably only get worse.

For now, I could get away by disabling assembly code in the 32bit avcodec library, but in order to get that going I had to study the Chromium code carefully – Google does not use the standard autotools or cmake configurations that the Average Joe would employ when compiling ffmpeg, instead they re-invent the wheel every so often to keep everyone on edge. First it was Gyp, but that did not work out too well and the current fad is called GN (as Google state themselves “GN is a meta-build system that generates Ninja build files so that you can build Chromium with Ninja“).

Some time soon, I need to dissect Chromium’s embedded ffmpeg code, to see if I can get assembly code compiling again on 32bit. Else it may be more prudent to start depending on an external (system-wide) ffmpeg installation, which I can compile without any pain on 32bit Slackware.

We’re fine for now, at least. Let’s hope it does not get worse.

Get your chromium 64 packages for Slackware 14.2 and -current:

Cheers, Eric

Chromium is now compiled using clang

October 30, 2017 / / 10 Comments

chromium_iconIn my previous blog post about Chromium 62, I described the issues I had while attempting to compile it on Slackware14.2. The gcc compiler suite on Slackware 14.2 is “too old” for Chromium because it lacks the required C++11 support. More to the point, the Google developers use clang instead of gcc for their own compilations and therefore gcc support is becoming stale. Response by Google developers when they encounter a gcc-related bug report is to ‘please switch to clang’.

Unfortunately, as previously noted, the chromium build framework will download Google’s own clang binaries in that case. I do not trust these binaries on my Slackware computer. I stated that I would not switch to clang until it became possible to either use Slackware’s own clang or else compile Google’s clang from source on my own computer.

I exchanged a couple of emails with Google developers and got enough hints to convince me that compiling Google’s clang was possible.

And indeed, after a week of trial and error (especially the 32bit build gave me headaches) I managed to add all the needed bits and pieces to my chromium.SlackBuild.

The updated packages for Chromium (version 62.0.3202.75) for which the sources were released last week, are compiled with clang instead of gcc, and that clang has been compiled from source first. Of course, this adds time to the package build… every time I compile the chromium package, the SlackBuild script has to download and compile clang as well. But, the process is fully automated and a separate “gcc5” package is not needed on Slackware 14.2. Also, we are future-proof now. And an added bonus is that the package size has decreased substantially, from 65 to 56 MB (a 14% decrement).

Note about the new Chromium release: it addresses CVE-2017-15396 (Stack overflow in V8) so it will be good to upgrade.

If you want to compile chromium using gcc nevertheless (to decrease the total build time for instance) then all you need to do is: set the variable “USE_CLANG” to “0”.
On Slackware 14.2 you still need my gcc5 package and apply the instructions from my previous post.

The packages for chromium are available for Slackware 14.2 and -current in my repository or one of its mirrors:

Have fun! Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑