I uploaded new 64bit packages for Chromium 118.0.5993.70 (also the un-googled variant) for which the sources were released a few days ago. This first release in the 118 series addresses a critical vulnerability (CVE-2023-5218) so it’s wise to upgrade.
As mentioned in a previous blog post, future 32bit package updates will have a lower frequency: one update per month. Google has increased the frequency of its Chromium releases dramatically (one per week) and I just cannot keep up. If you need that 32bit package badly now, you can of course grab the sources and my SlackBuild and build it yourself.
Looking at this 118 major release, one thing you need to be aware of is the changed behavior of “Enhanced Safe Browsing” which you can enable in the browser’s security settings (chrome://settings/security). Probably most of you already have this enabled. This is what changed:
Google will be able to disable an installed browser extension remotely if it determines the extension is labeled as ‘malicious’ and the extension was not installed via the Chrome Web Store.
The browser’s security checks of downloaded online content have been enhanced with so-called ‘deep scanning’ meaning the browser may now ask you for a password to open a protected archive you just downloaded. Note that the scanning occurs in Google’s datacenter – when you enable ‘enhanced safe browsing’ you consent to uploading some of your data to Google for the specific purpose of scanning and analyzing it for malicious content.
Also with ‘enhanced safe browsing’ enabled, the browser will send telemetry data about installed browser extensions using the chrome.tabs API to Google’s servers for analysis. This is meant to improve the “detection of malicious and policy violating extensions”.
It is up to you to decide which way the tradeoff between enhanced security and sharing data with Google works for you. If you don’t feel comfortable with this and you value your privacy, then you need to disable (or not enable) ‘Enhanced Safe Browsing’ in the settings.
Find the updated Slackware 15.0 and -current packages both for chromium and chromium-ungoogled in my repository and its mirrors (like my own US server and in a short while, the UK mirror).
Cheers, Eric
Thanks!
Thanks Eric for this update!
Thanks Eric!
Of course all the “Enhanced Safe Browsing” functionality is not present in the ungoogled version. But I don’t want it. I consider my own common sense more trustworthy then Google. And in doubt, there’s always virustotal.
Thank you Eric for keeping up-to-date with Chromium release.
I find this “one-per-week” release cycle a bit concerning for you (as a packager). I hope your workflow is mostly automated so that you don’t spend your FOSS/spare time on these packages (Googled and Un-googled versions).
It’s not automated at all – unfortunately the compilation of Chromium is a hit-or-miss and I get the occasional compiler segfault. Since it takes more than 11 hours to compile a single chromium package here, I quickly lose *days* when I have to go on a bughunt or restart the compilation (from scratch) after a crash. All of this needs to happen in the half-hour before I go to work or the few hours after diner.
That’s why there’s almost nothing else coming out of the house in terms of package updates or other projects.
If I may suggest: with a manual workflow, wouldn’t it more sustainable to voluntarily limit yourself to monthly package release or a least to package only releases fixing critical vulnerabilities (hoping that critical vulnerabilities won’t happen in each weekly release)?
You owe us (users of your packages) nothing. Create packages as you see fit.
If one wants the latest bleeding edge, one can always grab your Slackbuilds and go on their own compilation bughunt.
Hope this helps.
It may come to that if my time becomes more limited or if other projects need priority – I see a KDE Plasma6 nearing usable state and want to look into that.
For now, only the 32bit packages get an update frequency of once per month.
Having a safe browser is also important for me 😉
There are other ungoogled builds available on the internet. The “only” problem is to determine whether or not their origin is trustworthy.
I know you think the above is cursing in the church, but nevertheless …
Regards, Dick
Yeah, you should take care not to throw the child away with the bathwater… 😉
Yah, well… I do not trust any browser software on my Linux box unless I know and trust the people who compiled it. Meaning, Pat or myself.
Thanks yet again for keeping up with these rapid-fire updates, especially ungoogled-chromium. TKS
Hi Eric I hope your well and sleeping better. Not related to chromium, but i’m having issues with building 64bit current vlc I’ve got all dependency’s installed. The build fails with these 2 errors.
grep: /tmp/build/tmp-vlc/vlcdeps/usr/lib64/pkgconfig/libavcodec.pc: No such file or directory
sed: can’t read /tmp/build/tmp-vlc/vlcdeps/usr/lib64/pkgconfig/libavcodec.pc: No such file or directory
I’ve checked /tmp/build/tmp-vlc/vlcdeps/usr/lib64/pkgconfig/ and it’s not present. I have ffmpeg installed from your repo.
Sam
Hi Sam,
My vlc package contains its own ffmpeg libraries, it does not depend on a system ffmpeg.
The error you show, is not what is actually relevant. The real error will have happened a lot earlier during compilation of the embedded ffmpeg libraries.
The patch which is required to compile the ffmpeg in slackware-current is this: https://git.videolan.org/?p=ffmpeg.git;a=patch;h=effadce6c756247ea8bae32dc13bb3e6f464f0eb
I will apply this to my vlc.SlackBuild script to allow compilation on -current to succeed. Note that i compile my vlc packages on 15.0 for better compatibility so I did not catch this need.
I will update my public repository soon with the modified SlackBuild script and the required patch. I am currently compiling the package on -current to validate that this is all it needs.
Update: I updated my repository, as well as the mirror servers that I control. Other mirrors will get the updates during the next 24 hours.
Thanks very much eric thats great i’ll check the build repo and try again. Sam
Thanks the patch cured the problem compiled and built. I only compile as I dont use pulseaudio/pipewire or have it installed on my system as it causes to many issues for my setup with jack2 and co.
Hee Eric. when you’re compiling the next Chromium ungoogled, would you be willing to include this patch so I can tell them it works in linux too?
https://github.com/ungoogled-software/ungoogled-chromium/issues/2524
No worries if you don’t.
I expect that this patch will work in Linux, why wouldn’t it?
I will not implement it in my build because I actually find the new behavior quite useful and to me it makes no sense to simply disable this new behavior.
Now, if someone created a patch to bring back that “chrome://flags/#omnibox-bookmark-paths” flag you mentioned, then everyone would get what they want. I would apply that patch.
To me “ungoogled chromium” still means, the Chromium browser freed from Google’s spying. If people start adding/removing functionality on a whim, then for me that means the end of building chromium-ungoogled packages.