Distributors entering Flatpakland [LWN.net]

Distributors entering Flatpakland

Posted Jul 8, 2022 23:43 UTC (Fri) by bluca (subscriber, #118303)
Parent article: Distributors entering Flatpakland

> While packages can share the same runtime, there is nothing to prevent a proliferation of runtimes and versions; that already seems to be happening to an extent.

IMHO this is the biggest wasted opportunity that should have been handled from day 1. In the long term it would have been much better for the whole ecosystem if the stores (like flathub) strictly enforced two rules:

- if a library/dependency is available in a runtime, JoeRandomDev is actively forbidden from bundling it (bonus points for static linking checks!)
- runtimes are curated by the store maintainers and tightly maintained (and prevented from proliferating), and JoeRandomDev is not allowed to upload a runtime

Sure it would have costed some additional pain in the short term, at the beginning. But I think it would have been worth it to end up with a much cleaner, healthier and safer ecosystem overall.

to post comments

Distributors entering Flatpakland

Posted Jul 9, 2022 11:46 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

> But I think it would have been worth it to end up with a much cleaner, healthier and safer ecosystem overall.

Sure, if your goal is to stick with 1% market share forever and ensure everything would be totally pure and clear it would be a worthwhile goal.

> Sure it would have costed some additional pain in the short term, at the beginning.

That's what I was hearing for last 20+ years about .deb and .rpm based approaches, too.

Distributors entering Flatpakland

Posted Jul 9, 2022 12:35 UTC (Sat) by bluca (subscriber, #118303) [Link] (1 responses)

Why would any of that happen if instead of infinite runtimes, there was a couple dozens? Even fewer considering extensions would cover pretty much every use case

Distributors entering Flatpakland

Posted Jul 9, 2022 19:32 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

Then all the Gentoo users would be out of luck.

Distributors entering Flatpakland

Posted Jul 9, 2022 13:03 UTC (Sat) by alonz (subscriber, #815) [Link] (1 responses)

I would much prefer a mechanism based on transparency, rather than blunt enforcement:

Each distribution will declare a set of "blessed" runtimes, containing the components it considers critical;
If a flatpak overrides any component from the "blessed" runtime, and the flatpak's version lags behind the "blessed" one - show a warning banner: "This package uses an old version of some libraries, and may introduce security vulnerabilities".

Sure, some users will just ignore these warnings. But some will not, and this could be an effective hammer to force packagers to behave more responsibly.

Distributors entering Flatpakland

Posted Jul 9, 2022 15:20 UTC (Sat) by bluca (subscriber, #118303) [Link]

When supply chain security is involved, The Right Thing (TM) should just happen. Warnings, even if seen, mean it's too late already.

Can the runtime be upgraded?

Posted Jul 9, 2022 13:14 UTC (Sat) by epa (subscriber, #39769) [Link] (2 responses)

So, suppose a security hole is found in a commonly used Flatpak runtime — the version of zlib it includes is vulnerable, say. Is it just a case of distributing a new runtime, installing it to replace the old one, and all Flatpaks that use it are now fixed?

Can the runtime be upgraded?

Posted Jul 9, 2022 14:42 UTC (Sat) by smcv (subscriber, #53363) [Link]

Yes, if apps Foo and Bar use (for example) the freedesktop.org Platform 21.08 runtime, then upgrading the fdo Platform 21.08 runtime is usually enough to give both Foo and Bar a fixed copy of zlib.

Similarly, if Foo uses the GNOME runtime and Bar uses the KDE runtime, and both the GNOME and KDE runtimes are based on fdo Platform 21.08, then having the maintainers of the GNOME and KDE runtimes trigger an automatic rebuild against fdo Platform 21.08 is usually enough to give both Foo and Bar a fixed zlib.

The only time this would not be enough is if Foo and Bar are statically linked to zlib, or build and bundle their own zlib in /app/lib, or otherwise have their own private copy of zlib instead of using the runtime's. Traditional distro packages have the same limitation, of course.

Can the runtime be upgraded?

Posted Jul 9, 2022 14:45 UTC (Sat) by dbnichol (subscriber, #39622) [Link]

Yes (once the application is restarted). Almost all (or possibly even all) of the actively used runtimes are based on the Freedesktop runtime - https://gitlab.com/freedesktop-sdk/freedesktop-sdk. Once it's fixed there and the other runtimes based on it are rebuilt, the vulnerability can be updated in all applications.