My thoughts on Slackware, life and everything

Tag: google (Page 1 of 16)

Multiple Chromium updates in rapid succession

You may have noticed that after my release of the Slackware package for Chromium (and its Un-Googled sibling) version 146.0.7680.71 there was a really short interval until I released an update in the form of the 146.0.7680.75 version.

Chromium 146.0.7680.71 is the latest major version upgrade and it addressed a crazy amount of CVE’s. I am not even going to lookup and configure the URLs, here’s the list:

CVE-2026-3913 CVE-2026-3914 CVE-2026-3915 CVE-2026-3916 CVE-2026-3917 CVE-2026-3918 CVE-2026-3919 CVE-2026-3920 CVE-2026-3921 CVE-2026-3922 CVE-2026-3923 CVE-2026-3924 CVE-2026-3925 CVE-2026-3926 CVE-2026-3927 CVE-2026-3928 CVE-2026-3929 CVE-2026-3930 CVE-2026-3931 CVE-2026-3932 CVE-2026-3934 CVE-2026-3935 CVE-2026-3936 CVE-2026-3937 CVE-2026-3938 CVE-2026-3939 CVE-2026-3940 CVE-2026-3941 CVE-2026-3942

And then the next update to 146.0.7680.75 only two days later included 2 zero-day security fixes that the developers missed somehow: both for CVE-2026-3909 and CVE-2026-3910 an exploit exists in the wild.

And then already the next day, a new update emerged which I am currently compiling: Chromium 146.0.7680.80 sources were released to address yet another zero-day exploit, this time CVE-2026-3909.

Those new packages (chromium and chromium-ungoogled 64bit binaries) will become available tomorrow, Sunday if the compilation does not fail. The 32bit package for chromium-ungoogled will follow a day later. The last two attempts to build a 32bit package had to be aborted when I discovered that there was a new release. I have only one computer that is capable of compiling Chromium, and building packages in parallel is not an option.

Enjoy the weekend and be careful accessing shady web sites 🙂

Eric

Chromium source tarball availability

Someone asked how I am creating Chromium (also -ungoogled) packages these days? When you download my SlackBuild script and attempt to build the package yourself, the script will error out because it cannot download the sources.

For weeks now, the Google automation is broken with regards to creating Chromium source tarballs. Apparently some bug prevents their CI/CD pipelines from succeeding. This is reportedly fixed for the Chromium 132.x releases (currently their Beta versions) but Chromium 130 and now also 131 releases are announced without their accompanying source tarballs.
I have therefore created a script which fetches the needed stuff from git and packs that into a “chromium-$VERSION.tar.xz” tarball. You will find it in the “build” directory and it’s called “fetch-chromium-release.sh“. You run that script with a Chromium official version number, wait a long long time, and you end up with the 6+ GB source tarball which you can then move into your local “build” directory.

Hope that clarifies things and helps you compile chromium or chromium-ungoogled yourself.
Have fun! Eric

July update for Chromium 126

The latest release of the Chromium source code (version 126.0.6478.182 was made available on July 16th) addresses several vulnerabilities as usual, some of which are rated as ‘High’ but none ‘Critical’ and also no new 0-days are reported.

You can fetch my Slackware 15.0 and -current packages both for chromium and (hopefully soon, because its source has not been released yet) also chromium-ungoogled . You may prefer one of the mirror servers (like my own US server and in a short while, the UK mirror) in case my primary slackware.nl server is not responding or too slow.

I am slowly transitioning back from being a caregiver for my mother (which absorbed me completely for 10 months) to a life where I have time and energy in the evenings to hack on Slackware again. You will soon find the next installment in the Slackware Cloud Server series here on the blog – an article dedicated to building a Docker stack as cloud storage backend for the open source Ente Auth 2-factor authentication app.

Cheers, Eric

Authenticators for 2FA

Multi-factor authentication: it is difficult to find high-profile websites these days that allow you to get away with a simple password-based login. It’s a sobering thought to realize how fast your ‘secure’ password can be hacked using sophisticated techniques that go way beyond brute-force cracking.

So, multi-factor authentication has become the rage. When you authenticate yourself, you increase the security of your account by providing multiple ‘factors‘: something you know (a password or PIN code); but also something you have (a cryptographic identification device or a token); and something you are (which could be a biometric quality such as a fingerprint or a face-iD).

When requiring 2 of these factors,  we talk of ‘two-factor authentication’, better known as ‘2FA’. Then, usually these will be the use of a password combined with the string of digits (a token) produced by an authenticator – whether that is a hardware device or a software implementation.

Popular are authenticator apps on smartphones. Google, Apple and Microsoft have their own authenticators which you can find in the respective stores for your smartphone. They are really easy to use and completely interchangeable – every authenticator will generate the exact same code for a website at the same moment in time.
The disadvantage of these authenticators becomes clear when you lose your smartphone… gone are the authentication codes you need to logon to your account! You’ll have to contact customer support to disable your 2FA so that you can access your data again, and then re-enable 2FA using an authenticator on your new phone.

That’s why Authy became so popular: this is an authenticator which stores your 2FA tokens securely in the company’s (Twilio) cloud storage. With Authy, you can authorize another device (smartphone or desktop) to generate the same 2FA codes for you. And as long as you remember the passphrase which encrypts your cloud-stored tokens, you do not need your original phone to authorize a new phone. Really convenient!
Unfortunately, Authy does not offer a way to export your tokens from their app.  It’s total vendor lock-in as it happens so often. And this month, Authy’s Windows and Linux desktop applications stop working, leaving only Android and iOS as supported platforms for your authenticator. On top of that, there was a recent breach of Authy’s cloud storage, leaking 30+ million email addresses associated with Authy accounts. That facilitates phishing attacks of course, but also, when you try to recover your account after the loss of your phone, Authy would first ask for your phone number and then continue granting access to the related account. Security updates to Authy apps on all platforms are now preventing application initialization based on your phone number, but it speaks a clear message: if you cannot fully trust the company providing you with one of two authentication factors, it may be time to switch.
But, the lack of export capability… indeed.

I have been using Authy for a couple of years, precisely because of the convenience it offers in the rare case that you lose (access to) your phone. Now being really pissed about the vendor lock-in, I went to look for an acceptable alternative authenticator. And I found Ente Auth. It is an open source 2FA authenticator, with the option (not mandatory) to create an account at Ente and sync your local 2FA tokens to their cloud server.  The end-to-end encryption used by Ente has been independently audited,  and the app allows you to both import (from other authenticators that are not Authy) as well as export your tokens. Ente’s server offers a read-only version of the authenticator interface which means, after login you can find your 2FA codes in your browser as well.
Switching from Authy to Ente Auth was a slow and painful proces, where I had to disable and re-enable 2FA on many web sites, but now I am ready to use Ente Auth exclusively. I can only highly recommend this app.

What’s more: Ente has also open-sourced its backend server. Ente is first and foremost an open source and secure alternative to Google Photos or iCloud: a place to store your photos and videos. But the authentication backend has been built as a standalone functionality from the start, which allowed the company to build Ente Auth around that backend. By open-sourcing the backend, you can actually have complete control over cloud-storage of your 2FA tokens! An account on ente.io is then not needed, you simply instruct the authenticator app to connect to your own server address.
And as a bonnus, you also get a secure and self-hosted alternative to Google Photos.

If there’s an interest in a follow-up article explaining how to self-host the Ente Auth server backend, let me know in the comments section below.

Have fun! Eric

Chromium update fixes 5th zero-day exploit for 2024

In Google’s release notes for the latest Chromium 124.0.6367.201 source code it is  mentioned that this release fixes a zero-day vulnerability. Beware: this is already the 5th zero-day which was reported and fixed in Chromium in 2024.

This vulnerability is already actively exploited in the wild, and is labeled CVE-2024-4671, so please upgrade your chromium and also ungoogled-chromium packages as soon as you can.

You can fetch my Slackware 15.0 and -current packages both for chromium and chromium-ungoogled . You can also visit mirror servers (like my own US server and in a short while, the UK mirror) in case my own server is not responding or too slow.

Note that I still do not provide 32bit package updates for Chromium and Chromium-ungoogled. It is a lot of work to find out how to compile rust and llvm on 32bit Slackware ‘the Google way’ and so far the solution has eluded me.
I need these custom rust and clang compilers to compile Chromium sources on 32bit.
And please don’t tell me ‘to look at how Debian does it’ – it does not help.

Cheers, Eric

« Older posts

© 2026 Alien Pastures

Theme by Anders NorenUp ↑