Alien Pastures

My thoughts on Slackware, life and everything

Tag: nacl

Hello Chromium 63 – goodbye NaCl

December 18, 2017 / / 15 Comments

December usually is a busy month, with the focus at work to wrap up as much of the ongoing projects as possible and prepare for the christmas holidays. And when there’s a lot of (paid) work to do, the voluntary work gets second place. That’s why there was not really a lot of time to churn out a Chromium 63 SlackBuild script. Two weeks ago the first sources for release 63 appeared online and fixed a lot of (security) bugs. Last week saw an update and this is what I grabbed and packaged, because you can’t wait too long with addressing security issues.

Those of you who had examined my chromium-dev.SlackBuild a while ago will already know that the SlackBuild for versions beyond 63 needed a bit of re-work to cope with changes at the source level. I am glad I did that in November, as it made the transition for the stable browser much easier.

Starting with this package, I am no longer compiling (P)NaCL by default. NaCL, or the Native Client, is a way to run applications in a sandboxed browser process at near-native speed. The PNaCL binaries are platform-independent which means one executable (.pexe) can run in Chrome/Chromium browsers on all supported platforms/architectures. Google announced in May 2017 that it would stop supporting NaCL in the first quarter of 2018 in favor of WebAssembly which is a new cross-platform cross-browser solution to run high-performance applications. Both Mozilla’s and Google’s browsers already support WebAssembly, Microsoft and Apple are getting there too. You can experience an impressive WebAssembly demo here: The Zen Garden based on Epic’s Unreal Engine.

You can of course recompile the chromium package if you need NaCL. The chromium.SlackBuild script defines a variable “USE_NACL” which used to be set to “1” and now defaults to “0”. If you set it back to “1” and run the SlackBuild script, you will get your NaCL support back.

The reason that I stopped compiling NaCL support is pretty basic.
Last month it became clear to me that many Google developers are not caring about anything else than their own ecosystem. Call me naïve. The compilation issues I was experiencing with the GCC compiler were dissed with a remark that internally, Google uses a patched version of Clang which does what they need and standards-based code is not really at the top of their list. Any issues I had with gcc (along with packagers of other distros), they were not going to fix. The anticipated but unhelpful answer was to just download and use Google’s Clang binaries. But that goes completely against the idea behind my own chromium package… do not rely on the Google binaries (aka Chrome) and instead build natively on Slackware.
It forced me to find a way to compile the Chromium sources using their ‘Google hack’ of the Clang compiler.
So when helpful people at Google (they too exist of course… not all of them are so single-minded) showed me how to download the Google Clang sources, compile that first and then use those binaries to compile Chromium in turn, it dawned on me.
All this time I had been downloading and using Google binaries anyway: the (P)NaCl code is compiled using a pnacl binary toolchain which gets downloaded from Google during the compilation of the Chromium sources. That was the moment where I took the decision to stop with providing NaCL support in my package, and make sure that all the binaries I need for the chromium package are compiled natively on Slackware.

Get chromium 63 packages for Slackware 14.2 and -current:

New Chromium: 32.0.1700.77

January 17, 2014 / / 2 Comments

chromium_icon Chromium is the Open Source variant of the Chrome Browser. Both are part of the Chromium project which also has the Chrome OS as a product. Chromium and Chrome share the same codebase, and the closed-source Chrome browser is enhanced with some proprietary features like Adobe’s Pepper Flash plugin.

A new stable release (32.0.1700.77) for the Chrome/Chromium browser has been revealed a few days ago.

It took a little to get the official sources – there was an issue with the Google build bot which creates the source tarballs. I did a successful test build with a tarball I created myself (see below for the recipe if you’re interested) and reported the issue of the missing sources in the packagers Google group. Eventually official sources became available and I rebuilt both packages (i.e. 32-bit and 64-bit) using this tarball.

Get my Chromium packages in one of the usual locations:

You can subscribe to the repository’s RSS feed if you want to be the first to know when new packages are uploaded.

There are some nice new features in this new “32” release. The browser tabs will show a small speaker icon if that page is playing audio, and a “play” triangle if video is playing on the page. Another enhancement (not yet experienced here… perhaps I never will 🙂 ) is that the browser will warn about potentially harmful pages and downloads in a more directly visible way. And if you have kids, now there’s this new feature called “supervised users” where you can define  sub-accounts to your main Chromium account and limit access to sites for those (as well as being able to monitor their browesing history through a new Google control panel).

Apart from all the fancy new stuff, this release is just as much about squashing (security) bugs. You can check out the release page for that, here are the most interesting fixes, quoted directly from the announcement:

  • [$1000][249502] High CVE-2013-6646: Use-after-free in web workers. Credit to Collin Payne.
  • [$1000][326854] High CVE-2013-6641: Use-after-free related to forms. Credit to Atte Kettunen of OUSPG.
  • [$1000][324969] High CVE-2013-6642: Address bar spoofing in Chrome for Android. Credit to lpilorz.
  • [$5000][321940] High CVE-2013-6643: Unprompted sync with an attacker’s Google account. Credit to Joao Lucas Melo Brasio.
  • [318791] Medium CVE-2013-6645 Use-after-free related to speech input elements. Credit to Khalil Zhani.

If you are new to Chromium and in particular my Slackware-packaged version of it, you should definitely check out my previous post on Chromium where I explain the build requirements and use of API keys that allow you to use the official Google storage for data synchronization and such. That post also mentions more about some extensions to Chromium (PDF viewer and Flash player) which you can extract from the official binary Chrome package.

A few sites to play-test your Chromium browser:

  • http://www.zygotebody.com/ – the Body Browser, using WebGL for fast realtime rendering
  • http://www.quirksmode.org/html5/tests/video.html – HTML5 video tests (several encodings like H.264, WebM and Ogg/Theora)
  • http://www.naclbox.com/ – NaCLBox is an implementation of DOSBox in Chromium’s Native Client, guaranteeing near-native speed of the applications running in the sandbox. NaCLBox offers a lot of good old DOS games which you can play directly in your browser window. Note that my package contains the Native Client (NaCL) whereas the version you can compile using the SlackBuilds.org script will not add NaCl.

Have fun! Eric

PS: this is a script which I wrote as documentation of the manual steps I took to create my own unofficial release source tarball when I got fed up waiting for the official one:

#!/bin/sh
#
# Checking out the sources of an official chromium release,
# by Eric Hameleers
#
# In a working directory, you will create three directories:
# - depot_tools: this contains all the tools needed for creating the tarball
# - checkout: here almost 7 GB of sourcecode will be checked out
# - output: here the chromium-${RELEASE}.tar.xz source tarball will be created.
#
# Some variables:

WORKING_DIR=”${HOME}/chromium_src”

CHROMIUM_REL=”32.0.1700.77″
DT_REPO=”https://chromium.googlesource.com/chromium/tools/depot_tools.git”
RELEASES_URL=”https://src.chromium.org/chrome/releases”

# The actual work (takes a while);
# Checkout 1 GB of source and pack it up:
mkdir -p ${WORKING_DIR}
cd ${WORKING_DIR}

# Clone the depot_tools:
git clone ${DT_REPO}

# Check out the sources:
mkdir ckeckout
cd checkout
PATH=”../depot_tools/:$PATH” gclient config ${RELEASES_URL}/${CHROMIUM_REL}
# At this moment, your config will have been written to a file ‘.gclient’
PATH=”../depot_tools/:$PATH” gclient sync 2>&1 | tee ../sync.log
# The sync will download everything, based on what it found in this file:
# ${CHROMIUM_REL}/DEPS
PATH=”../depot_tools/:$PATH” gclient sync 2>&1 | tee ../sync.2.log

# Pack up the source tarball:
mkdir ../output
python src/tools/export_tarball/export_tarball.py –remove-nonessential-files ../output/chromium-${CHROMIUM_REL}

echo “”
echo “Resulting source tarball is: ${WORKING_DIR}/output/chromium-${CHROMIUM_REL}.tar.xz”
echo “”

It produced a 169MB tarball. I needed a couple of “gclient sync” commands before I finally had all the source code (hopefully all… I have no way of checking if anything is missing).

Chromium for Slackware, with salt & pepper

November 23, 2013 / / 87 Comments

chromium_icon I have been using Chrome alongside Firefox for some time now, because I was not very happy with the way Firefox is growing fat and sluggish.

Chrome is nice and fast, and it allows me to save my preferences and bookmarks so I can keep them synchronized across computers – just like Firefox for which I setup my own private Sync server, However, Chrome is a closed-source app and I prefer to run open source self-built stuff where possible. Enter Chromium.

Chromium is the Open Source variant of the Chrome Browser. Both are part of the Chromium project which also has the Chrome OS as a product. Chromium and Chrome share the same codebase, and the closed-source Chrome browser is enhanced with some proprietary features like Adobe’s Pepper Flash plugin.

The slackbuilds.org site has a chromium SlackBuild script – it’s been there since Slackware 13.1 and Chromium 9. Building the package takes several hours which in my opinion is too long to simply ask people to compile it themselves. Just like with other big packages like LibreOffice, I decided to build my own package for Chromium and add that to my repository. What better time than right after the release of Chrome/Chromium 31.0.1650.57, last week!

I did some research, to see what I needed to put into my SlackBuild. The one on slackbuilds.org for instance, does not build the Native Client. It also does not define a Google API key or OAuth tokens. Without these API keys, some features of Chromium that use Google APIs will not be available in the browser. Think of Chrome sync, push messaging, remote desktop sharing, safe browsing, search suggestions and more.

Therefore I decided to request my own set of API keys from Google for my Chromium package build. I got those (it is an automatic process, and it is cost-free). The license restricts you in the use of these API keys: you are not allowed to make them public, they are for your personal use only. However there is an exception for distribition packagers and so I also applied with Google to allow me to share these API keys with the Slackware community. I got that approval in writing today and I will share my keys in future builds of the package.

For now, I chose to not to add them to the SlackBuild, because I want to have feedback from you Slackware users first, about the stability and the functionality of my Chromium build. Google can block a browser based on the API key with which it was configured and I want to make sure that everything is OK before uploading them into public view. I have uploaded my API keys so that you can recompile the package yourself and get a fully functional browser. It is explicitly not allowed to re-distribute my API keys when you create a modified version of my package!!

If you run my SlackBuild script without having API keys of your own, it will build you a perfectly working package – you just will not be able to sign into Chromium. If you want to recompile Chromium using my SlackBuild script and with Google API key, you can always generate your own API/OAuth keys by following the procedure outline on http://www.chromium.org/developers/how-tos/api-keys of course. Add the key definitions to a file called “chromium_apikeys” in the same directory as the chromium.SlackBuild, it will look somewhat like this:

_google_api_key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
_google_default_client_id=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com
_google_default_client_secret=XXXXXXXXXXXXXXXXXXXXXXXX

Note that you are then not allowed to distribute these keys. Good luck! It compiles for 5 hours in my virtual machine and it needs many GB of swap file for the final link stage.

And then about Native Client. The Native Client is a sandbox technology that allows developers to write applications in native code (code targeting the machine hardware) and running that code inside the Chromium browser. The advantage is that these applications are able to run at near-native speed. Google has made several of these NaCL applications available in the Chrome Web Store. A nice gallery of NaCL applications is hosted at https://developers.google.com/native-client/community/application-gallery It features free-to-play games like Don’t Starve and Lara Croft, and even has a SSH secure shell ( I use that one on my own Chromebook).

I had no idea how to build the Native Client so I looked at how Suse, Arch, Debian and Ubuntu build their Chromium packages. Turns out, not everybody adds the Native Client. In the end I adopted the way Arch Linux builds it by downloading Google’s NaCl SDK and using  that to build my own binaries.

There are two caveats at the moment, when building all of this. Both these points apply only to compiling Chromium… they do not apply to running the browser.

  1. On 32-bit Slackware 14.1 you’ll have to rebuild the “libelf” package with this patch:
    --- libelf.SlackBuild.orig 2011-03-27 06:24:58.000000000 +0200
+++ libelf.SlackBuild 2013-11-22 17:24:17.740039844 +0100
@@ -38,7 +38,7 @@
 NUMJOBS=${NUMJOBS:-" -j7 "}

 if [ "$ARCH" = "i486" ]; then
-  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
+  SLKCFLAGS="-O2 -march=i486 -mtune=i686 -D_FILE_OFFSET_BITS=64"
   LIBDIRSUFFIX=""
 elif [ "$ARCH" = "s390" ]; then
   SLKCFLAGS="-O2"
  2. On 64-bit Slackware 14.1 you’ll have to go multilib if you want to compile the Native Client. If you do not want to add multilib you can set the internal SlackBuild variable “USE_NACL” to “0” and the Native Client will not be built. You get all the other features still, of course.

Get my Chromium packages in one of the usual locations:

You can subscribe to the repository’s RSS feed if you want to be the first to know when new packages are uploaded.

Lovers of word games, you’ll have noticed that Native Client is shortened to NaCl which is another notation for salt. Guess what, apart from the salt, Google also added pepper to their browser. The Pepper Plug-in API (PPAPI) is a cross-platform API for plugins for web browsers, meant to replace the Netscape Plugin API (NPAPI) which (according to Google at least) is flawed and belongs to the past. The best known Pepper based plugin is Adobe’s Flash Player. Adobe abandoned their NPAPI based plugin (but they still apply security fixes) and focus on their PPAPI plugin for Chrome. Good news: Chromium works withe PPAPI plugins and therefore it is possible to extract the Flash plugin from Chrome and use it with Chromium. Check out this package (first install chromium, then chromium-pepperflash-plugin because the second package updates the chromium configuration defaults). Because this is a proprietary plugin, by installing it you agree to the Chrome End User License Agreement.

Note: Chrome/Chromium are going to block most NPAPI plugins at the beginning of 2014 and support for The Netscape API will supposedly be dropped altogether at the end of that same year. Another note: Mozilla’s Firefox will start enforcing “Click to Play” even before the end of 2013, which means that plugins will no longer be loaded automatically, but only after the user (you) clicks on a “Play” button. All plugins, meaning for instance the popular Java and SilverLight, but excepting the most recent Flash.

Tell me your experiences with Chromium for Slackware!

Eric

Note (20131124):

  • I have uploaded my API keys so that you can recompile the package yourself and get a fully functional browser. It is explicitly not allowed to re-distribute my API keys when you create a modified version of my package!!
  • Also, I have added Google Chrome’s proprietary PDF viewer as a separate package for Chromium:  http://www.slackware.com/~alien/slackbuilds/chromium-pdf-plugin/ so that PDF files can be viewed inside the browser.

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑