Chromium security issues caused by outdated packages in Debian with security issues exploited in the wild is resolved for now.
Debian uploaded the same version
87.0.4280.88-0.4~deb10u1 to Debian
Its good that they pushed the sid version to buster, but this doesnt
mean this issue wont happen in the future and this isnt a permanent
guaranteed solution that we can rely on. (The package though still being
removed in the next debian version bullseye)
The question remain how long will debian take to upgrade chromium 87 to
8x , or will it ever move or upgrade from this version to another one.
Yes, situation has to be monitored.
Does the chromium flatpak package have any issues which the chromium Debian package has mentioned in Chromium Debian Package Security?
Not yet suitable.
Download for Debian-based systems
Repository for Debian-based systems
current version 2019.04.73 - outdated
(based on Chromium 73.0.3683.103)
But interesting to watch how this project develops.
What about plain Chromium via extrepo?
There is no such thing as an extrepo repository. extrepo is a method of enabling an already available repository (such as deb.torproject.org, deb.whonix.org, …) in an easier way. Instead of following third party instructions on how to enable the third party repository (add apt signing key + add apt sources.list.d snippet) it simplifies that process. No third party repository with alternative Chromium versions to being with -> extrepo repository cannot help either. Similar explanation:
Iridium uses an ancient version of Chromium and is therefore publicly vulnerable to known vulnerabilities, all whilst the developers blatantly lie to its users on Github about this. It also severely weakens the browsers exploit mitigations by e.g. switching from Clang to GCC (so no CFI, etc.) for seemingly no reason; they just apply dangerous patches for the sake of it.
Chromium doesnt support OpenPower CPUs (No builds for ppc64 within debian)
Thats should be better to not link it to google.
Counter measures In response to a report that a tracker was using CNAMEs to circumvent privacyblocklists4, uBlock Origin released an update for its Firefox version that thwarts CNAME cloaking . The extension blocks requests to CNAME trackers by resolving the domain names using the browser.dns.resolve API method to obtain the last CNAME record (if there is any) before each request is sent. Subsequently, the extension checks whether the domain name matches any of the rules in its block lists, and blocks requests with matching domains while adding the outcome to a local cache. Although uBlock Origin also has a version for Chromium-based browsers, the same defense cannot be applied because Chromium-based browser extensions do not have access to an API to performDNS queries. As such, at the time of this writing, it is technically impossible for these extensions to block requests to trackers that leverage CNAME records to avoid detection
Indeed. This is good news. The transition isn’t nice for users but from Freedom Software viewpoint, it is good that Open Source code interacting with proprietary API has been removed.
Viewing the situation as of
14 March 2021:
- Remotely exploitable Chromium security vulnerability CVE-2021-21193 is as reported by Google being used in the wild.
- Unfixed in Debian.
- Unfixed in Chromium on Flathub.
- Unfixed in Chromium on Snap Store.
- Fixed in official Google Chrome (non-freedom!) version.
Chromium is basically all independent upstream. The relevant ones available for Kicksecure all lag behind with security critical updates.
Viewing the situation as of
03 April 2021:
- Both, FlatHub and Snap Store had a more than 2 weeks gap between Google reporting a security vulnerability being exploited in the wild and these software stores pushing an upgrade.
- Debian chromium package is still vulnerable.
Exploited in the wild is a crucial difference here. That’s the line between theoretic considerations and security in the real world.
03 April 2021
firefox-esr on Debian Security Tracker
- One unimportant issue.
- No security vulnerabilities reported being exploited in the wild.
chromium on Debian Security Tracker
- 6 CVEs.
- At least 1 vulnerability reported being exploited in the wild.
Due to my above two posts and this post…
https://madaidans-insecurities.github.io/firefox-chromium.html may I suggest to replace
It sounds right in theory but all the security mitigation in Chromium didn’t help to avoid this vulnerability being exploited in the wild. We should prioritize security in the real world over theoretic considerations. Despite all security innovations in Chrome / Chromium, that didn’t actually help users in the real world if Chromium maintenance (new releases with security fixes) lags behind Chrome. Maintenance is unfortunately something that cannot be excluded from the security comparison.
Now for more than 2 weeks Kicksecure would have had the choice to either install by default:
- Firefox: No security vulnerabilities reported being exploited in the wild.
- Chromium: At least 1 vulnerability reported being exploited in the wild.
More theoretic considerations…
Additionally, users on the Linux platform  had to choice:
- to use non-freedom software Chrome + vulnerable being to Google Chrome Repository Insecurity
Kicksecure Freedom Software doesn’t have the chance to install Chrome by default because it would then become non-freedom software. Even when mixing Freedom Software with non-freedom software, I wouldn’t know if Chrome could be legally re-distributed. I haven’t found license agreement for Chrome yet.
The question of the Kicksecure default browser, Debian’s Firefox ESR (or from any other Firefox from alternative sources) versus any Chromium unfortunately now got less clear to me.
 Leaving out Windows from considerations since this is about what to do in Kicksecure, Freedom Software, Linux based.