On Mon, Jun 5 2023 at 01:05:25 PM -0500, Chris Adams
<linux@xxxxxxxxxxx> wrote:
It's layered, but from what I understand, an upper layer depends on a
specific build of a lower layer. So using the up-thread example, if
there's a security update to zlib, the lower layer can rebuild to pick
it up, but until the upper layer (like say LO) also rebuilds on top of
the new lower layer, they'll be running on the old version.
Well, *generally* that is entirely untrue. But sometimes it really is
true.
That's the simple answer. Apologies for turning this into an essay, but
there's no simple way to explain this. There are two different
considerations here.
Point 1:
TL;DR what Adam Williamson already said is correct.
Flatpak itself only knows about two layers: the runtime and the
application. You do have to rebuild the application to use a new
*major* version of the runtime (comparable to new major versions of
Fedora), but not for normal updates of that runtime. Let's
hypothetically say that your app is using the GNOME 44 runtime and
there is a bug in the zlib provided by the runtime. You do not need to
rebuild your app for users to get the new zlib. However, let's say your
application is instead using the GNOME 42 runtime, which is end of life
and won't receive any further updates. To get the updated zlib, the
application has to update to the newer GNOME 44 or 43 runtime, and
users will suffer from the zlib bug until it does so.
You can think of different versions of the runtimes as entirely
different runtimes: org.gnome.Platform/x86_64/42,
org.gnome.Platform/x86_64/43, org.gnome.Platform/x86_64/44. Each
runtime receives regular updates independently from your application,
but you have to update your application to switch between major
versions. It's a compromise between updating too much and breaking your
app, vs. updating too little and leaving users to suffer from bugs and
security issues.
(Compromise is a theme of Flatpak: the split between runtime vs.
application is also a compromise between which dependencies are updated
by the runtime maintainers, comparable to traditional distribution
maintenance, vs. which dependencies are bundled and have to be updated
by application maintainers, at the mercy of the app developers'
attentiveness.)
Point 2:
But now, to make things more complicated, sometimes runtimes and
applications are *themselves* built from different layers. Flatpak
itself doesn't know about these layers, and most Flatpak users don't
know about it either, and I wouldn't have even mentioned it here except
for your comment, but when you build things this way, you really do
have to rebuild the upper layer to update the lower layer. This is why
I couldn't say your comment was entirely incorrect.
Let's start with runtimes. For example, the GNOME runtimes
org.gnome.Platform are based on the freedesktop-sdk runtimes
org.freedesktop.Platform. zlib is actually maintained as part of the
freedesktop-sdk, so we do not have our own GNOME packaging for zlib:
it's all inherited from freedesktop-sdk. We do have to manually update
the GNOME runtime to use a newer version of freedesktop-sdk. That is,
when we update the zlib element in freedesktop-sdk, users do not
actually receive the newer zlib until we update the freedesktop-sdk
element in the GNOME runtime. That happens regularly, but it does
introduce delay. The GNOME and KDE runtimes are both based on
freedesktop-sdk, so these are layered runtimes. The freedesktop-sdk
runtime is not based on anything else. Then the Fedora runtimes are the
only runtimes I'm aware of that are not based on freedesktop-sdk. So
some runtimes are layered, and some are not.
Now, most applications are just a single layer, but some include a
"base app" which is basically a way for multiple applications to share
the same set of bundled dependencies between themselves. Most
applications do not use base apps, but if you do, then you do need to
rebuild the application in order to update the dependencies from the
base app. I think Flathub *could* theoretically do that for you
automatically, but I've asked and I'm told it doesn't. What do base
apps look like? I searched Flathub for "base" [1] and it looks like
base apps are mostly used for web engines. For example, there is an
io.qt.qtwebengine.BaseApp and that seems to be how Flathub applications
are expected to use QtWebEngine. This means that apps using QtWebEngine
need to be careful to monitor for updates and rebuild as required, or
else users will wind up using old versions. This is not great, but at
least it's somewhat better than manually bundling your own QtWebEngine.
(In contrast, WebKitGTK is part of the GNOME runtime, so applications
don't have to worry about updating it and can trust that the runtime
maintainers will handle that.)
Conclusion:
* Runtime maintainers are responsible for updating dependencies that
are components of the runtime (including freedesktop-sdk)
* Application maintainers are responsible for updating components that
are bundled into the application (including base apps)
The Flatpak security model assumes that application code is bad and
riddled with security vulnerabilities, so updating dependencies is not
as important as it is for host applications. In theory, vulnerable
applications are not the end of the world, because a compromised app is
heavily sandboxed with extremely limited access to the host system and
no ability to do harmful stuff. In practice, this does not yet work
very well at all; see [2] for more info on that.
Michael
[1]
https://github.com/orgs/flathub/repositories?language=&q=base&sort=&type=all
[2]
https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
