My thoughts on Slackware, life and everything

Tag: 32bit

Respect all little bits

I finally figured out how to successfully compile the 32bit version of Chromium (and its un-Googled sibling) on Slackware, now that this requires the Rust compiler to build it. Pat added the final bits that I needed to the rust.SlackBuild script in Slackware recently.

Why did it take so long? Basically ‘real life’ intervened and I did not have time left to investigate.

I assume there may be one or two users left who use my 32bit Chromium package, the rest of you simply don’t care whether I can produce these 32bit packages or not. No one reached out and asked, can I help?
Prime example of slackers, right? It is what it is, and I respect that, and honestly I understand; there’s no fun in having to deal with all these Chromium developer assumptions that everyone uses Ubuntu. Kudos to the Ungoogled-chromium team however – they have been really helpful whenever I got stuck.

The bottom-line is, that I will resume my builds of a 32bit version of Ungoogled Chromium, once per month, for Slackware 15.0 and -current, until the process breaks again and then it’s goodbye to 32bit Ungoogled Chromium.
In any case, there will not be further 32bit packages for the regular Chromium browser going forward. I will remove the existing 32bit chromium packages from my repository because I want to prevent people downloading a vulnerable browser.

Eric

Update – I have uploaded 32bit packages:

+--------------------------+
Mon Aug 12 20:13:12 UTC 2024
chromium-ungoogled: updated 32bit to 127.0.6533.99 (Slackware 15.0 & onwards).
  If your browser keeps crashing with seccomp errors, add this as startup
  parameter: "--disable-seccomp-filter-sandbox".
  For reference: https://alien.slackbook.org/blog/chromium-90-packages-again-32bit-related-issues/

Chromium 90 packages – again 32bit related issues

There’s new ‘chromium‘ and ‘chromium-widevine-plugin‘ packages in my repository. And chromium-ungoogled packages will follow soon.

Chromium was upgraded to 90.0.4430.72 but unfortunately the 32bit package which I have built (twice) crashes immediately on startup. This happens both on Slackware 14.2 and on -current. The error message looks like it is something different than the glibc-2.3x related seccomp crash behavior in the previous Chromium 89.x releases.
Since I don’t have hardware that is running a 32bit Slackware OS and could only test on QEMU virtual machines so far, I can not confirm with 100% certainty that the new Chromium will or will not work on your 32bit Slackware OS, which is why I also kept the older 32bit chromium-89.0.4389.114 package in the repository.
Let me know about your experiences down here in the comments section! I am getting tired of begging Google developers not to break 32bit binaries every major release. I’d be grateful if people running 32bit Slackware who are affected by the 32bit Chromium crashes, would chime in. Else I will eventually have to drop 32bit support.

There’s also an updated Widevine plugin package, unfortunately Google only released this newer version for 64bit systems. The new 64bit package has version “4.10.2209.1” whereas the 32bit package remains at version “4.10.1582.2”.
Note that this Widevine plugin is meant for chromium-ungoogled only. The ‘real’ Chromium does not need or use it, since Chromium downloads this CDM library automatically for you.

Have fun!
Eric

Chromium 64 – and 32bit pain

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 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 2.6.37.6 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

© 2024 Alien Pastures

Theme by Anders NorenUp ↑