Fedora's missing Chromium updates

I think you're in violent agreement, he said "very few people" want to do the work, not no one.

> If we need significant investment in application development at the distro level around things which aren't distro-specific, something is off track.

From upstream's perspective, there are several options for providing up-to-date binaries, and they all suck in one way or another:

1. Build and maintain packages yourself, and tell users to add your server as an extra repo. Main downside: Have to do this for every distro you care about (probably Debian and/or Fedora at a minimum, but if you only do one, then users of the other will ask/demand that you support it, or else they will try to install it themselves with third-party deb2rpm/rpm2deb tools, and now you're in the business of de facto supporting that use case). Some users will complain that it's not in their distro's standard repo (which might even be a valid complaint, if the product happens to be FOSS). Main upside: You have a real package manager handling installation, but at the same time, you retain maximal control over what that package manager will actually do.
2. Build and maintain packages yourself, and get them added to the official repo. All the downsides of (1), with the additional downside that you have less control over the package and have to "play nice" with the distro's rules. Arguably, that's a good thing, since many of these packages are poorly made, but from the perspective of upstream, this is extra work and "office" politics. Also, if one of your developers gets into a stupid argument with somebody on a mailing list, some journalist might decide that it's newsworthy, so now your PR people have to be aware that that's a thing. Main upside: If you do it right, distro devs will like you for making their lives easier. Also, installation is relatively easy for the end user.
3. Provide a flatpak or one of the equivalents. Main downside: Everyone will say that you are bad and wrong for vendoring everything, and also it will use up more disk space than the other options once installed. Main upside: It Just Works™ on the vast majority of reasonable systems, at least assuming you built it right.
4. Provide a tarball. Then you lose everyone who doesn't either have a compiler installed or know how to install one, and on top of that, you probably also lose a good 5-10% of the remainder to weird configure/make errors. But at least it's less work (you just run autoconf and tar/gzip everything up).
5. Be popular enough that some/most distros are willing to do (2) for you. Main downside: If they screw up the packaging, you'll probably get blamed for the resulting misbehavior of your application. Main upside: No work at all (but practically speaking, it's "polite" to at least offer tarballs so that distros have a reasonable starting point).

TL;DR: There is real work that has to be done, somebody has to do it, and upstream is only going to do it if they think it is in their interest to do it.

1. I must apologize for not being clearer in my original comment. I only wanted to focus on complaints about Chromium maintenance and make it a slight against Martin Stransky's work on Firefox. However, if Firefox is only on Fedora due the heroic work of one person and the vast number of people expecting it to work are not putting any effort in it, then it is a Not In My Back Yard problem. They want it, they know they need it, they know it is required, but putting in the work to make it work would mean having to give up something they prefer so meh let someone else take the work.

2. I don't know what to do with your second paragraph. If it isn't part of the distributions work (and the people who consume said distribution) to help the upstream browsers make it work, then whose is it? The browser companies have already a full hand working on 98% of the desktops they could deploy to by keeping things working Windows and MacOS. Add to that their largest share is on phones which dwarf the amount of work needed for desktops. If it is the consumers of Firefox/Chromium to do so themselves, then why do they even need a distribution?

One other thing I failed to do was to say that I am as guilty as many others on this. Tom and Martin have been doing lots of work and I have done zip to help them. I just expect my browser to work when I come in the morning and I move on.. just like I expect my water in my pipes to be clean and my garbage to be picked up.

Now what I can do to get out of this position is going to be hard, but well I have to do so.

This situation really makes me sad. Indeed, browsers have become full-blown operating systems. They're so complex that they can barely be qualified as opensource in that me, you or most users cannot even figure how to enter this to adjust their unpleasant behaviors, let alone build them. So we just have to undergo, just as if they were proprietary. And I suspect that there's a strong disconnection between browser developers and those doing the packaging. To me it looks like "take it as is, period" (i.e. download the binary). The level of effort that the packagers have to provide just to get such essential components packaged seems tremendous and unrewarding. Maybe if such too painful packages were dropped at some point, their developers would make an effort to improve modularity, build dependencies and everything that results in so much pain for packagers.

In my opinion, packagers should probably only be bothered by porting to architectures that are not in the upstream developers' focus but only on their distro's focus. But at least on default architectures, opensource software should definitely build out of the box and not require thousands of dollars of hardware investment to see a build complete in less than 24 hours :-/

Those having to do that painful job have my sympathy, as I gave up trying to build my browser more than a decade ago, and without their efforts I would probably just be using outdated and vulnerable binaries.

Hi,

Browsers are not an operating system, and browsers makers are not able to deliver an operating system (otherwise FirefoxOS would have been a direct success).

Browsers are complex apps that reach deeply inside the operating system. Therefore browser devs *have* to work with their upstreams to feed changes and fixes there.

However they tried the usual dev shortcut of bundling because it is “someone else's problem”® and it is cheap and fast (at first). And now the whole card pile is about to crash (happened so many times before, see Java log4j etc).

There is no good solution short of browser makers becoming OS makers themselves or learning to work better with OS makers. Either way would force them to un-bundle things since os-level monorepos are unmanageable.

But, humans being humans, people will stress the system to the breakpoint to avoid doing things they do not want to do.

I have the same experience. I do not build Chromium any more on my Gentoo systems and in fact considering it does not have significantly more features than Firefox I consider the Chrome/Chromium codebase incredibly bloated because it takes so much longer to build.

In which case, check your /etc/apt/sources.list is current and contains the correct lines:

deb http://deb.debian.org/debian bullseye main non-free contrib
deb-src http://deb.debian.org/debian bullseye main non-free contrib

deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

# bullseye-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02....
deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

or thereabouts.

$ apt policy firefox-esr
firefox-esr:
  Installed: (none)
  Candidate: 91.6.0esr-1~deb11u1
  Version table:
     91.6.0esr-1~deb11u1 500
        500 http://security.debian.org bullseye-security/main amd64 Packages
     78.15.0esr-1~deb11u1 500
        500 http://ftp.debian.org/debian bullseye/main amd64 Packages

Debian stable systems are expected to have apt sources for both bullseye and bullseye-security (or whatever version they are on, bullseye being the current stable release) to get timely security updates. It's a bit like the way Windows has (or used to have?) individual security updates for individual security issues (those are like a bullseye-security update), and also "service packs" that collect lots of security and non-security fixes into one big release (those are like a bullseye update).

The bullseye-security suite is where the security team put new security updates that correspond to a security advisory. It has chromium 99 and firefox-esr 91 already. Other packages with recent-ish CVEs have updated versions in bullseye-security, for example Flatpak 1.10.7 and expat 2.2.10-2+deb11u2.

The bullseye suite is slow-moving, and is only updated during point releases every couple of months. 11.2 is the latest, and 11.3 should ideally have happened during February (but presumably the stable release managers have been too busy). At the moment it's still on chromium 90 and firefox-esr 78 (and Flatpak 1.10.5 and expat 2.2.10-2), but chromium 99 and firefox-esr 91 (and Flatpak 1.10.7 and expat 2.2.10-2+deb11u2) will be copied from bullseye-security into bullseye during the 11.3 point release. Point releases also include fixes for non-security-related bugs (there's a non-security GTK update queued up for 11.3, for example).

I believe the reasoning behind this is that it means the critical path for issuing new security updates involves a much smaller package-set than the entire Debian archive (because it doesn't have to include any packages that haven't needed a security update during this release cycle), which makes it lower-overhead for the security team to manage, so they can ship security updates sooner. It also makes it more feasible to use time-limited signatures on the metadata, so that people can detect a malicious or broken proxy, mirror or ISP holding back updates that they should have received.

Ubuntu security updates are also like this, but more so: in Ubuntu, a released suite like focal *never* gets updated, and all package updates (including security fixes) happen via focal-security or focal-updates.

I use flatpaked browsers for testing occasionally and have no complaints. As long as I can take screenshots, download into ~/Downloads, and open URLs from other apps I'm happy. Seems like flatpak would be a reasonable option for fedora's chromium build and that would let them relax trying to replace bundled deps.

You are welcome. Keep up the good work on the Flatpak!
There is nothing on the page on flathub that hints on it being *not* official. Maybe it is a good idea to make that clear.

I use this flatpak (as a secondary browser, for websites that don’t support Firefox) and it Just Works for me. Thanks for all your work!

The Firefox devs have some privacy blind spots and Icecat has fixes for a number of them. I appreciate the work that gets done to make the Icecat fork of Firefox.

When I looked a month or so back, konqueror actually uses qtwebengine these days, as Arch implied, although the only official konqueror documentation I could find suggested otherwise. And it was only by using it on an updating page (a news feed) that I could see in 'top' that it was using qtwebengine. It's really hard to work out what it uses, probably does a dynamic link.

The other kde browser, falkon, also uses qtwebengine, and unlike the rest of qt5 you can get current versions of that from git. Of course, although the qt devs are good at backporting CVE fixes, qtwebengine5 is stuck on chrome 87 and therefore python2.7. But falkon does work on some websites that only work with chrome or its derivatives .

Haven't used dillo in a long time, but I'm quite impressed with how snappy it is compared to Firefox (on lwn.net).

> Given that Google (presumably) doesn't care all that much right now ...

If patch acceptance depends so much on whims of a single entity then IMO it's "open" and "free" only on paper.