Fedora packages versus upstream Flatpaks

Posted Feb 7, 2023 23:10 UTC (Tue) by koh (subscriber, #101482)
In reply to: Fedora packages versus upstream Flatpaks by mb
Parent article: Fedora packages versus upstream Flatpaks

Why wouldn't distributions be able to

> keep up with. e.g. browsers?

Fedora packages versus upstream Flatpaks

Posted Feb 7, 2023 23:23 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (5 responses)

Bugs in a browser are very critical. Any delay with an update compared with the upstream release directly put the users at risk. And then with Chromium-based browsers it may takes hours to compile the thing unless one has access to a very expensive computer (it took 6 hours on a beefy ThinkPad laptop from 2021 the last time I checked) . So a distro may not have resources to do it timely.

Fedora packages versus upstream Flatpaks

Posted Feb 8, 2023 8:29 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

That is actually more of a Chrome -based browser problem. Firefox compiles just fine in much more reasonable amounts of time.

Fedora packages versus upstream Flatpaks

Posted Feb 16, 2023 16:23 UTC (Thu) by mrugiero (guest, #153040) [Link] (1 responses)

Why is this? Since C++ build times seem to be (somewhat) shorter than Rust's and Firefox is Rust+C++ while Chromium is just C++, I would have expected the opposite. Is there any kind of explanation?

Fedora packages versus upstream Flatpaks

Posted Feb 16, 2023 17:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I believe that Chrome's source is still quite a bit bigger than Firefox. Firefox 110 sources are 476MB in a `.tar.xz`[1] while Chromium was 555MB as of Chromium 59[2] and I assume has only grown since then (finding tarballs is…not easy as the instructions are all git-based).

The build mechanisms may also vastly differ. From my time with WebKit building, there is a *lot* of generated code (which I assume Chrome still has). I have no idea how much codegen Firefox does though.

[1] https://ftp.mozilla.org/pub/firefox/releases/110.0/source/
[2] https://github.com/zcbenz/chromium-source-tarball/release...

Fedora packages versus upstream Flatpaks

Posted Feb 8, 2023 18:06 UTC (Wed) by koh (subscriber, #101482) [Link] (1 responses)

I believe this argument to miss the relations of spent time involved in the process. As far as I understand, the sequence of events you summarize is:
0. vulnerability is found and exploitable
1. disclosure of a vulnerability to the respective browser development team
2. implementation of a fix for it
3. testing the implementation and verifying that it actually solves the problem
4. release of new browser version
5. distributions start building new browser version
6. distributions send out new packages
7. users install distributions' updates

The risk you mention exists as of time T0 where event 0. happened until T7. You appear to refer the time T5 to T6 as a critical delay, though as a simplification building the software by distributions (5.) takes exactly as long as a single test in point 3. Potentially also point 2. depending on whether the developer uses incremental builds for it or not. T6 can be seen as instantaneous. I would argue that neither T3 nor T5 are of significance here. It's rather T0, T1 and T2 that influence risk most heavily.

Fedora packages versus upstream Flatpaks

Posted Feb 8, 2023 18:15 UTC (Wed) by pizza (subscriber, #46) [Link]

> 6. distributions send out new packages
> T6 can be seen as instantaneous.

This definitely isn't true; there's typically some internal distro process that delays things (eg promoting from updates-testing to updates).

At the same time, even when getting the binaries straight from the browser maker via their automated update mechanism, the updates aren't pushed to everyone simultaneously either; there's typically a staged release.

Even then the delay between the packages/binaries being available to when they're actually applied (whether the binary comes from the distro or the browser vendor directly) usually requires the user to acquiesce to having the browser restarted, and IME is typically the longest pole in practice.

Fedora packages versus upstream Flatpaks

Posted Feb 9, 2023 22:35 UTC (Thu) by plugwash (subscriber, #29694) [Link]

Discalimer, i'm not a Fedora/redhat guy, my observations are from Debian/Ubunt,), I suspect the issues are similar on the other side of the fence though.

The problem with the two main web browsers chromium and firefox is:

1. Chromium doesn't produce lts releases at all and while firefox does, those lts releases still have quite short lifecycles compared to what the linux distros need.
2. They attract security issues at a rate that means distros consider doing their own secirity patch backports impractical.

The result is that linux distros are practically forced to update to new major versionsnof browsers even in stable releases.

My understaning is that packaging new versions of browsers for old versions of Linuc has vecome increasingly difficult due to various dependencies. Ubuntu recently threw in the towel and created transitional packages that install the snaps instead. Debian is still trying and seems to be doing an ok job with firefox esr but chromium in Debian has gone unmaintained for significant periods in the recent past.