Thread: Purism Librem Phone
View Single Post
MartinK is offline MartinK
2018-03-04 , 14:55
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#293
Originally Posted by marmistrz View Post
3. What's wrong with apt/yum/zypper/pacman or whatever Alpine uses that they want to go for flatpak? Why O(n) copies of libstdc++? (if my understanding of flatpak is correct) Who is going to update the dependencies when there's a CVE?
You are incorrect in both cases (multiple libstdc++ & CVEs) - Flatpak works with the concept of runtimes, which generally contain the core and security sensitive libraries and provide a stable API (per runtime major version). This way apps can share common dependencies & get CVE fixes automatically via runtime updates.

Of course, a few conditions need to be met for this to work:
  • apps need to be using dependencies provided by the runtime
  • the runtime needs to be maintained

So if an app bundles something on top of the runtime, that's not going to be fixed by runtime update if a CVE shows up. But! It might actually not consume extras space if many apps bundle the very same thing (on binary level) - all Flatpak apps on a system live in a single ostree repo, which should automatically deduplicate everything:

Flatpak uses OSTree to distribute and manage applications and runtimes. The repo/ in the above tree is the local OSTree repository. Flatpak creates the active/ directories of applications and runtimes as symlinks to OSTree checkouts (in the same directory). Using OSTree has the advantage that the checkouts are automatically deduped and share diskspace, since OSTree is using hardlinks and content-based addressing. OSTree also makes it easy to roll back to an earlier version, should the need arise. But the definition of the filesystem layout for applications and runtimes and the sandboxing implementation are not tied to OSTree in any way, and it is very possible to distribute runtimes and applications with a different mechanism.
It's some pretty clever stuff.

Also, Flatpak is not really a package management system as people generally understand it (RPM/DEB/etc.) but rather a dedicated system for distributing sandboxed graphical applications built against stable runtimes. As it is nota normal package management system you can do alo of stuff that's generally impossible with normal package management:
  • install multiple versions of an application
  • install applications without root privileges
  • install any flatpak on any distro as long as the required runtime is available on it
  • keep applications from touching stuff outside of the sandbox they have no reason to interact with (could be malware or badly coded apps)

Especially the last point it IMHO rather important if you want to support mobile apps the way people are used to them on mobile platforms (Android/iOS) - eq random application containers developed by random people submitted in binary form to an appstore.

As normal Linux software packages run scriptlets as root and there is zero sandboxing security in this case is based basically on a web of trust and code-review by distro package maintainers and I don't thinks that's going to scale for a mobile app store the way people are used to them on mobile platforms.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 17 Users Say Thank You to MartinK For This Useful Post: