Alien Pastures

My thoughts on Slackware, life and everything

Tag: chromium (Page 14 of 20)

Chromium 62 ready for download

October 20, 2017 / / 5 Comments

chromium_iconEarlier this week, Google released a security update for its chrome/chromium browser. The new version 62.0.3202.62 plugs the holes of 35 more or less serious issues, several of them have a CVE rating.
When the topic of Chromium 62 came up in the comments section of a previous post, I mentioned that I was unable to compile it on Slackware 14.2. Errors like “error: static assertion failed: Bound argument |i| of type |Arg| cannot be converted and bound as |Storage|” yield some results when looked up on the Internet, and they indicate that Slackware’s own gcc-5.3.0 package is too old to compile chromium 62.
The c++11 implementation in gcc-5.3.0 has issues which are fixed in gcc-5.4.0. Unfortunately we are stuck with what we have on Slackware 14.2; it will only get security fixes, no functional upgrades, so no gcc-5.4.0.

I posted on the chromium-packagers discussion group to see if there’s anything to be done about this and that lead to an e-mail discussion with a Google developer who is also a Slackware user. He told me that Google compiles its own Chrome with clang, and more specifically, using a modified bleeding-edge version of clang that does what Google wants it to do. Compiling with gcc is not tested all that much, which apparently is leading to a multitude of reports about gcc related compilation issues. It’s not just me.

There is a reason that I want to compile with gcc, even though the chromium.SlackBuild already has some (hopefully complete) support for using clang instead. Google does not want to use the system-clang of the distro and instead, forces a download of its own clang binaries. I am not ready to trust a binary black-box to compile my chromium package… after all I created the chromium package for Slackware so that we do not have to depend on Google’s Chrome binaries.
This entry on Google’s  reviewboard is encouraging though; there is an initiative to take distro packagers’ wishes more seriously. The idea is to work toward using the system toolchain to compile Google’s clang variant from source and then use that to compile chromium. I’ll wait for that to happen before I switch to clang. I have nothing against clang as compared to gcc – it’s only my unease at having to trust someone else’s binaries.
I hear you say “but what about NaCl?”… indeed in order to compile NaCl my chromium.SlackBuild is already downloading a binary toolchain from Google. But that downloaded PNaCl toolchain is not used to compile the complete browser, it’s used only for the NaCl sandbox. And even that is coming to an end. Google has deprecated (P)NaCl in favor of WebAssembly. As of April 2018, it will only support PNaCl in Chrome Apps and Extensions. Meanwhile, WebAssembly (a portable cross-platform and cross-browser solution for presenting web apps at near-native speed) is already fully functional in Chrome/Chromium, as can be seen by visiting http://webassembly.org/demo/

Back to the present day. I still needed to compile chromium 62 for Slackware 14.2 with its too-old compiler suite. Therefore I grabbed my gcc5.SlackBuild which I had originally meant to be installed alongside gcc7 on slackware-current. I polished it a wee bit, and then build packages for Slackware 14.2. My ‘gcc5‘ works by sourcing its “/etc/profile.d/gcc5.sh” script which sets several environment variables and points those to the gcc5 binaries (CC, CPP, GXX, AR, NM, RANLIB). Unfortunately, the chromium framework ignores these environment variables and uses the “which” command to look for gcc and g++. Therefore I had to be a bit more creative (i.e. break some stuff).

So, what is the drill on Slackware 14.2 if you want to compile Chromium 62?

  • Install gcc5, ninja and nodejs for which I have packages in my repository. Note that installing this ‘gcc5’ does not replace your Slackware gcc-5.3.0, it gets installed alongside and does not clash.
  • Download the chromium sources and scripts from my repository.
  • Make the ‘gcc’ and ‘g++’ symlinks in Slackware point to the ‘gcc5’ binaries:
    # cd /usr/bin
    # mv gcc gcc.orig
    # ln -s gcc-5 gcc
    # mv g++ g++.orig
    # ln -s g++-5 g++
  • Source the profile script (just to be sure). Note the ‘dot’ at the beginning, that dot is the ‘source’ command:
    # . /etc/profile.d/gcc5.sh
  • Compile chromium. Note that this requires lots of RAM and lots of diskspace, and if your CPU does not have many cores, you’ll need a lot of time too.
  • Restore Slackware’s gcc and g++ symlinks:
    # cd /usr/bin
    # mv gcc.orig gcc
    # mv g++.orig g++

Fortunately gcc5, ninja and nodejs are only needed for the compilation, not for actually running the browser. So if you do not fancy a re-compilation, you do not have to install any of those other packages.

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

Have fun! Eric

Chromium 60 packages available

July 29, 2017 / / 13 Comments

chromium_iconGoogle released chrome/chromium 60.0.3112.78 on 25 July. My mother-in-law passed away which shifted my priorities this week, but I found some time to compile new packages. In my VM, the 64bit package creation took more than 24 hours… perhaps now is a good time to look at that Ryzen CPU and empty my savings account. This is getting ridiculous.

Note that this is a security release, fixing 40 security issues. Of those, the following are classified as “high risk” (many of them do not yet have their details published at cve.mitre.org or nvd.nist.gov): CVE-2017-5091, CVE-2017-5092, CVE-2017-5093, CVE-2017-5094, CVE-2017-5095, CVE-2017-5096, CVE-2017-5097, CVE-2017-5098, CVE-2017-5099. So I guess you better do the upgrade.

Compiling Chromium requires ninja and nodejs for which I have packages in my repository if you need them. Fortunately ninja and nodejs are only needed for the compilation, not for actually running the browser.

The packages for chromium, and the Widevine CDM plugin (package is called ‘chromium-widevine-plugin‘), are available for Slackware 14.2 and -current in my repository or one of its mirrors:

Have fun! Eric

Chromium 59 – a security update

June 8, 2017 / / 6 Comments

chromium_iconGoogle released chrome/chromium 59.0.3071.86 earlier this week. This was accompanied by a rather big list of security updates.
Taken from the Red Hat Security Advisory: “Multiple flaws were found in the processing of malformed web content. A web page containing malicious content could cause Chromium to crash, execute arbitrary code, or disclose sensitive information when visited by the victim. (CVE-2017-5070, CVE-2017-5071, CVE-2017-5072, CVE-2017-5073, CVE-2017-5074, CVE-2017-5075, CVE-2017-5076, CVE-2017-5077, CVE-2017-5078, CVE-2017-5079, CVE-2017-5080, CVE-2017-5081, CVE-2017-5086, CVE-2017-5082, CVE-2017-5083, CVE-2017-5085)”

Otherwise, Chromium did not receive new functionality that immediately jumps out at me, except that the Chrome Settings page has changed its look and feel to Google’s “Material Design“.

Remember when you want to compile Chromium yourself, you will need ninja and nodejs (fortunately ninja and nodejs are only needed for the compilation, not for actually running the browser).

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

Have fun! Eric

Last week’s package harvest and more

March 19, 2017 / / 14 Comments

Last week I made my build server at home churn through a lot of packages, let me summarize what became available recently in my slackbuilds repository:

  • I added ‘NetworkManager-openvpn‘ which is a plugin for NM adding support for OpenVPN connections. I needed this for myself since I recently started using the services of Private Internet Access (PIA). All I needed in addition was the ZIP file with OpenVPN configurations. If you need more instructions about how to setup the PIA VPN let me know and I will wrote some more about that. I also added this plugin to my PLASMA5 Live Edition.
  • I upgraded ‘Handbrake‘ to 1.0.3 which also fixed the libvpx library error on -current.
  • I updated the Flash Player plugins for Mozilla and Chromium browsers to 25.0.0.127 (this is a security update).
  • I updated Chromium and its Widevine plugin to 57.0.2987.98. There is a slightly newer release out already but that will have to wait a bit.
  • I updated LibreOffice to 5.3.1 (packages for -current only but I will build them for 14.2 too).

I did more than that; I also updated the front page of my ‘bear’ server with the information that you can access it over secure HTTP (https), and added a link to my post about the CACert issue with Mozilla and Google browsers. Furthermore I added more detail about the dynamically generated ISOs for Slackware-current (the installation DVD and the Live Edition).

I will spend my next post writing about the new KDE 5_17.03 edition which I uploaded to my ‘ktown’ repository, but let me mention here that I already uploaded a new PLASMA5 variant of the Slackware Live Edition which contains a “work in progress” version of this new Plasma 5 release (work in progress because I decided to add more packages later). I did not mention that in any previous post.
Along with that Plasma 5 Live ISO I also uploaded a variant containing the very fresh MATE 1.18 (thanks to Willy for providing me with the tried & tested packages). So there is enough to play with 🙂
I am actually considering a new spin of the PLASMA5 Live ISO because it allows me to offer the complete KDE-5_17.03 including the Kdenlive non-linear video editor in the Live OS, along with the latest LibreOffice.

Enough for now, check out my follow-up post for the news about my new Plasma 5 ‘ktown’ release.

Have fun! Eric

I added Chromium 56 for Slackware 14.1 with a caveat

February 28, 2017 / / 7 Comments

chromium_iconA while ago, Chromium 56 ‘stable’ was released. It took a while for me to release Slackware 14.1 packages because of a crash bug in XFCE (and probably other non-KDE desktops too). I have been trying to find ways around the crash and been looking for patches, but there does not seem to be a solution for Slackware 14.1 other than working around it and losing some functionality.

So, what’s the issue?

Chrome/Chromium can optionally store credentials (user accounts, passwords) that you type in to access online secure web sites. The Password Store is a sqlite database. On Linux, its location is “~/.config/chromium/Default/Login Data” for Chromium and  “~/.config/google-chrome/Default/Login Data” for Chrome.
Chromium/Chrome on Linux wants to store your online credentials in a safe way, but it does not have the code itself to encrypt its own Password Store. Instead, it tries to rely on the availability of an external encryption provider. On KDE desktop environment, it will use the KDE Wallet system, while on other desktops it will try to use Gnome Keyring. If none of these are found, then Chrome/Chromium will fall back to storing unencrypted passwords in the above sqlite file.

Coming back to Slackware 14.1: there is a bug in it – probably in glib2 because that is where the segmentation faults are reported – which prevents recent versions of Chromium from using the Gnome Keyring. Within seconds of accessing the first web page in Chromium on Slackware 14.1, the browser will crash if you are running XFCE or some other non-KDE desktop. Note that you can use Chromium just fine in KDE on Slackware 14.1!

This issue does not exist in Slackware 14.2 or -current, probably because all the package updates between 14.1 and 14.2 solved the underlying issue. Therefore this bug is not something that will be solved in the chromium code by reporting it to Google… it is a OS related bug.

This means, if you are running XFCE you have to prevent Chromium from trying to use gnome-keyring. I tried to enforce the use of kwallet when running XFCE but that did not work, so you need to entirely disable the use of an encryption provider by adding the parameter “–password-store=basic” to the chromium commandline. The consequence will be that your online passwords will be stored unencrypted and anyone who gets hold of a copy of that sqlite file, will be able to extract all your credentials.

So here are some strategies for working with Chromium and not get bitten by the gnome-keyring induced crashes and keep your passwords safely encrypted:

  1. Encrypt your homedirectory or even your complete filesystem. With your files encrypted (using a password only you know) you reduce the risk of having Chromium store your credentials in plain-text in a sqlite file.
    Disk encryption using LUKS is something which Slackware supports during the installation. Full disk encryption is always recommended if you are using a laptop.
    If you did not opt for disk encryption during installation, but you still have more free disk space available than your /home directory tree is currently using, then you can create a new – encrypted – /home and move your existing data in there. This is an exercise that requires knowledge about cryptsetup and goes beyond the scope of this blog post.
  2. Switch to KDE. The kwallet storage is encrypted and it will not crash chromium like gnome-keyring does.
  3. Upgrade to Slackware 14.2. The gnome-keyring of this version of Slackware (and newer) will not crash chromium , so you can encrypt your online credentials in XFCE too.

And here is a chromium configuration file for Slackware 14.1 which will detect your Desktop Environment and will automatically add the parameter “–password-store=basic” to Chromium’s commandline for you if you are not using KDE. Copy the text below into a file called (for instance): “/etc/chromium/10-passwordstore.conf”:

# Use the basic (un-encrypted) password store,
# unless we are running KDE:
if [ ! "$XDG_SESSION_DESKTOP" = "KDE" ]; then
 CHROMIUM_FLAGS="$CHROMIUM_FLAGS --password-store=basic"
fi

Encrypting the passwords of your online identities will not make you 100% safe of course… even when your passwords are encrypted, Chrome/Chromium will make them plainly visible inside a browser window, by visiting the URL chrome://settings/passwords .

Note 1: The Windows version of Chrome encrypts the passwords it stores in “%UserProfile%\AppData\Local\Google\Chrome\User Data\Default\Login Data” because it makes use of a Windows API which requires the logged-in user’s password for the decryption.

Note 2: When you use the browser’s sync feature to store a copy of your online credentials in your Google Account, then those copies will be encrypted with your sync password, that only you know.

 

Download the Chromium packages for Slackware 14.1 (they were already available for 14.2 and -current for some time) from a mirror like these:

Have fun! Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑