Bastien Nocera wrote:
> Why do we care about FHS compliance inside a Flatpak?
Because the proprietary directory layout means the applications (and the
libraries!) have to be specially built for it, and in the worst case,
require code and/or build system changes to deal with it.
> And why would it be slower to release security fixes?
With system libraries, if there is a security issue in a library, the
library is updated by upstream, packaged, and delivered directly to the
user.
With bundled libraries, if there is a security issue in a library, the
library is also updated by the library's upstream, but then the bundle needs
to be rebuilt with the new library and the whole bundle has to be delivered
to the user. The extra step of rebuilding the bundle (which typically
involves an additional maintainer) is what takes extra time.
In the discussed approach where the Flatpak is composed from RPMs, the
library is updated by upstream, packaged, the Flatpak is rebuilt with the
new library, and that is delivered to the user. So the extra step happens
between the packaging of the library and the delivery to the user.
In scenarios where Flatpaks are shipped by upstream, they will also have to
rebuild the library in some way, or wait for their distribution to update
the package. But in addition, most upstreams will probably just do
cumulative updates of the libraries when they do a new release of their own
code (if at all!) and not do timely security updates at all.
There is also the efficiency issue of having to update the whole bundle,
which will encourage cumulative updates and discourage quick security
updates. If the bundle is updated for every library security update, there
will be a lot to download. People are already complaining about the size of
Fedora updates as it stands, without having to update dozens of huge bundles
whenever a commonly used library is updated.
And it is also not possible to just stuff all libraries into the runtime to
avoid this issue, because then the runtime becomes a huge pile of libraries
that the user may or may not actually use, and updating the runtime (which
would have to be done the more frequently the more libraries it contains)
becomes very inefficient due to its size.
> You forgot the positive changes such as:
> - sandboxing
> - dogfooding and testing for the sandboxing technologies
There ought to be better ways to sandbox applications than to turn them into
what is essentially a full container (i.e., almost a full VM, only minus the
kernel), bundling all the libraries. The split into an application and a
runtime that Flatpak does is only a partial workaround.
We really need sandboxing technologies that work with shared system
libraries (also allowing the code segments to be shared in RAM). And in
fact, we already have those technologies:
* Fedora ships and heavily promotes SELinux, which in fact, as far as I
know, is also part of the sandboxing technologies Flatpak uses.
* seccomp also looks very promising. Chromium (and QtWebEngine) is already
using it effectively.
Bundling libraries has many drawbacks, including security-related ones (as I
explained above). (It also wastes download bandwidth, disk space, and RAM.)
To really improve security, we must provide the benefits of sandboxing
without bundling libraries.
> - make it possible to create Flatpaks quicker for some more complicated
> apps
That just requires shipping the tools for third parties to use, not using
them to deliver software packaged by Fedora.
> - developers not having to learn GPG to sign their releases
That is a very weak argument. It is very straightforward to set up an RPM
signing key, not any harder than writing a specfile. And then you just run
rpmsign --addsign to sign the RPMs.
And in the end, you are just saying that Flatpak does away with a critical
security feature. Relying exclusively on the sandboxing for security is a
very bad idea. Sandbox evasion exploits exist.
> - more efficient update tracking than RPM (eg. no need to download 20 megs
> of metadata to know there's nothing to update)
But less efficient updating, because you will need to download much more
than 20 megs of bundled libraries. The only reason the metadata is smaller
is because there is almost no dependency information encoded (only a single
dependency on a runtime). But those dependencies are what makes installing
and updating packages so efficient! Flatpak throws away the main competitive
advantage of GNU/Linux!
And it is actually possible to solve the metadata size issue, see the work
on metadata deltas. (There was at least one talk at DevConf on this.)
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
