Why promoting flatpak for PureOS Store?


#22

Stale libraries
I think it’s unfair to compare flatpaks to the Windows “downloading random binaries from the internet” model. It’s true that apps bundle libraries, but flatpak really provides a middle ground between the traditional, fine-grained, repository model and the “bundle everything” model.

All the base libs are contained in runtime modules, that are shared between apps and updated separately. Other libs are bundled with applications. This means release cycles can be different and problems in libs can potentially be addressed faster. It does mean problematic libs can linger on if an app is not updated, but the stale lib will not be used by every other application.

Whether this is better or worse than the situation with distro-provided packages is not so clear. Orphaned runtimes or flatpak apps may have vulnerabilities that would have been fixed by a distro replacing an unsafe lib with a newer version. On the other hand, replacing a lib may break installed apps that depend on a certain version, and distros have been known for shipping outdated libs for years (e.g. WebkitGTK) because some packaged apps were not updated to use the newer version.


#23

Maintainers/curators and developers
Reading through this thread, I get the impression that some people think maintainers are a dime a dozen. They’re not, especially not in a company the size of Purism. And juggling lib dependencies is hard work, as is adapting apps to the distro when needed. This (and distro policies) leads to distros shipping old versions of software. And so, as users, we get to wait for features and bug fixes. Possibly for a long time.

For developers, this means being flooded by bug reports and feature requests for things that were already fixed, just because people don’t realize their distro provides an old version. Developers are not a dime a dozen, either, and their time and effort could be used for better things than dealing with those same reports over and over again.

Flatpak tries to fix that.


#24

Spreading malware
The apps in Purism’s flatpak repository can be just as curated as any package in their .deb repository. So I think flatpak won’t mean more malware on the phone, perhaps even less because when maintainers are relieved of some tedious adaptation/dependency work, they can audit the code more thorougly.

Of course, adding malware to apps outside of Purism repositories is still possible. But is getting a flatpak from a random place really any different from getting a .deb from a random PPA?


#25

Permissions
The standard Unix access control (based on user and group permissions) really isn’t sufficient for the kinds of applications we use now, and mobile platforms have tried to fix this by introducing new permission types. E.g. camera access, network access, address book access. The Librem 5 needs to do that too, as can be seen from various threads here. But the traditional distro repository model has no way for applications to declare the permissions they need, and no way for the system to enforce limitations. Flatpaks do, through the use of well-defined portals to specific functionality.

The portals system is still a work-in-progress, but probably our best bet to get anything going in this area. (Personally, perhaps I think portals, and permission systems as used on iOS and Android, are too coarse. I think I would like to see something akin to the Sandstorm.io model, which is fine-grained and organized a bit differently.)


#26

Sorry for the many posts, but the OP and this thread deals with so many different issues at the same time…


#27

Yes, we do. @jeremiah already clarified that before you posted. He also said that Purism ensures the quality (security-up-to-dateness of libs).

So, if we can establish that there are no draw-backs over a FOSS repository, then the natural question is:
Why not a simple repository?
Well, possibly there are expected advantages?
E.g.

  • You can use these FlatPaks easily, even if you don’t want to stick with PureOS! (e.g. UBports, or upcoming other distros that run on the Librem 5, and of course whatever you run on the Librem laptops)
  • A store that focuses on desktop applications (including games), not overwhelming Linux Newbies with a plethora of libraries and the power to break the system
  • A strong incentive for developers to enhance the FOSS eco-system, by visibility and monetary compensation
  • A way to sensibilize users that the development of free software does cost money, and that it is a noble thing to honor the developers.

I would be surprised if Purism planned to keep a (larger) amount of the money for themselves.
I think the role model for this shop is the one in elementary.


#28

Why portability is need ?

Portability is a foundational requirement for collaboration on applications, this is how you get Fedora developers interested in working on applications and libraries in Debian. It also means that fundamental libraries can work in GNOME and Qt, in embedded and on a laptop. Portability is a requirement.

The apps on PureOS Store need only to run in PureOS.

We want everyone to be able to have freedom, regardless of which OS they run. So apps that Purism creates need to run on the largest possible installed base.

The problem here is that the only reason to have portability is to run obsolete program

I don’t understand this statement. Portability can mean porting applications from one distro to another, from one Desktop Environment to another, from one chip architecture to another, etc. It has little to do with obsolete programs.

or to make easier for external software (and so probably proprietary ones) to run on PureOS.

A foundational tenet of Free Software is to not exclude any field of endeavor, instead of imposing restrictions, it grants rights to other people, and one of those rights is to make any kind of application you like as long as you comply with the license. We cannot impose any restrictions on ‘external’ software, nor should we.

This portability is what is killing maintainers.

You’ll have to provide more evidence.

Moreover, are you sure that you can support
the extra effort introduce by the multiplication of libraries due to the way how flatpak packs
libraries ?

This is a question that we cannot answer at the moment definitively. It is a new technology and it is unclear if the investment in time is ultimately effective, but we believe we need to have an app store that supports our platforms and values and feel that flatpak offers us the fastest way to get there.


#29

Once you have a Linux kernel on your device, you can generally run any distro, either via a Docker container or chroot or similar.


#30

To be clear, Purism is not prioritizing accepting payment for apps for the app store. Our initial goal is to create something that is easy to use and matches our values. The prioritized, key requirement as of today is for that app to be in the app store, it has to be free software.


#31
We envision PureOS Store as the primary community interface for app developers to contribute
to the wider ecosystem, without having to understand the underlying technology like packaging
or the mechanism of pushing apps upstream.

This is exactly what I call giving more power to developer and striping it to maintainers. Why
does the dev need to know how packaging ? This is the role of the maintainer. Using flatpak
does not enable better contribution from the dev, It allows them to distribute the software
more easily which weaken the extra layer of defense provide by the maintainer.

Sadly, this is an idealized description of the roles of developer and maintainer. Oftentimes the developer is the maintainer and decides on using a particular packaging technology, like a tarball, and they don’t care about other formats, like rpms, flatpak, snaps, etc. A maintainer for your favorite distro is then a good thing to have. But even if you have a maintainer for your distro, it doesn’t mean that there is suddenly a layer of security, even if your distro is Debian. Maintainers are human and mistakes can and do happen, this is why isolation is important – if you limit access to only one means of IPC, you limit the amount of damage a mistake can cause.


#32

It does however mean that the user can trust that the source corresponds to the binary, since the user gets the binary from the (already trusted) distro maintainer who compiles it from the source provided by the developer.

How is this addressed in the flatpak/store model?

Edit: On Android there are many apps with published source code where the binary in Google’s store contains additional libraries, e.g. analytics and who knows what else. This doesn’t happen with Debian.


#33

What I don’t understand is why build another app store? Purism seems so focused on upstream support: why not improve Gnome Software to a stage where it does what Purism needs it to do?


#34

Personally I find it a good idea and also necessary. Excellent because it ensures that the applications you download are open source and controlled and necessary because somewhere you have to easily find applications for the phone. Also, I think that, as well as for other Stores, if they put the possibility of making donations, the number of programmers who will make software for the phone will increase. So, the librem will make a second version of the phone and more and more users will buy it etc. etc. (fact that I wish this company and open source in general). Finally, creating a store is not difficult.


#35

From @lipu

Reading through this thread, I get the impression that some people think maintainers are
a dime a dozen. They’re not, especially not in a company the size of Purism

It’s normal, you first need to bootstrap. For the moment, I do not think that PureOS
is widespread like Arch, Debian, Gentoo, CentOS, etc. It’s because it is, for the
moment, not widely adopted that there is not enough maintainers. If your distribution
gather enough people, you will have maintainers. Arch, Debian, Gentoo, etc do not
have problems with packages…

As a side note, and correct me if I’m wrong, my understanding is that a flatpak is built for a specific processor and thus not portable across architectures. Flathub is for Intel/AMD only - at least I see no place where I can select anything else there. The Librem 5 will have an ARM-based chip, which is completely different. So, the flatpaks currently available from Flathub will not be usable on the Librem 5.

Yes your probably right, you caught me. But nothing prevent Flathub to create ARM apps
specially for the Librem 5.

I think it’s unfair to compare flatpaks to the Windows “downloading random binaries from the internet” model. It’s true that apps bundle libraries, but flatpak really provides a middle ground between the traditional, fine-grained, repository model and the “bundle everything” model.

All the base libs are contained in runtime modules, that are shared between apps and updated separately. Other libs are bundled with applications.

Each flatpak packages can pack whatever libraries It wants. So yes, flatpak bundled
packages like Windows. Saying that some libraries are globally used using “runtime”
does not change that fact.

Moreover, here I’m not sure about the following, but, at first look in the doc, runtimes
are hosted in Flathub and so the distribution are not in the control (Flathub manage
the runtime updates, etc).

Whether this is better or worse than the situation with distro-provided packages is not so clear. […] In the other hand, replacing a lib may break installed apps that depend on a certain version, and distros have been known for shipping outdated libs for years (e.g. WebkitGTK) because some packaged apps were not updated to use the newer version.

This is an interesting remark but honestly do you think that it’s better to have some packages
with the new updated library if all the rest of your package use the old one ? I think that it’s
better to change the source code of the majority to support the new library and then, after,
force the old library transition on all apps. Moreover, do you think that the library transition
will go faster (or will even complete) if each package knows that its libraries will always work
due to flatpak ?

Of course, adding malware to apps outside of Purism repositories is still possible. But is getting a flatpak from a random place really any different from getting a .deb from a random PPA?

There is two problems that make it worse :
1. It makes the software run reliably in the time
2. It makes possible to create one package to infect all distributions

So, with flatpak, it is much more easier to develop one package to
rule them all and this gives tremendous power to software providers.

From @jeremiah

Sadly, this is an idealized description of the roles of developer and maintainer. Oftentimes the developer is the maintainer and decides on using a particular packaging technology, like a tarball, and they don’t care about other formats, like rpms, flatpak, snaps, etc.

A maintainer will probably be a dev for the distribution that he loves and this does
not shocked me. This is not a problems because, even if it’s a dev, it must comply
with maintainer rules or it will be fired (and if no other maintainer takes its package,
it will not be able to integrate it anymore).

A maintainer for your favorite distro is then a good thing to have. But even if you have a maintainer for your distro, it doesn’t mean that there is suddenly a layer of security, even if your distro is Debian. Maintainers are human and mistakes can and do happen, this is why isolation is important – if you limit access to only one means of IPC, you limit the amount of damage a mistake can cause.

Once again, I’m not against isolation but does isolation imply packing libraries ? Why do you
associate the two ? Namespace, cgroups and seccomp do not depends on libraries. Thus,
you can have a package description format that do not pack libraries and integrate isolation.

I don’t understand this statement. Portability can mean porting applications from one distro to another, from one Desktop Environment to another, from one chip architecture to another, etc. It has little to do with obsolete programs.

I think that you make a confusion, I’m not talking about portability
in general. I’m talking about portability in the context of flatpak
which mean packing the libraries into the package. All these arguments
refers to source code portability which is different than packing libraries.

Note: I think that it is good if all distribution will reach agreement
on 2 or 3 package formats (and thus on 2 or 3 package managers).
Convergence on some universal package formats are ok but these format
must not enable the packing of libraries.

This portability is what is killing maintainers.

You’ll have to provide more evidence.

Ok, I have a bit overstated this but the truth is that the goal of flatpak is to give
full power on devs. And, now, you know what I think this means for maintainers.

In my opinion, it goes even further, flatpak was developped with major goal to
enable users to install and use reliably prorietary softwares on Linux. Precisely,
it was developped to make possible and App Store or an Android Store on all
available Linux distributions.

We want everyone to be able to have freedom, regardless of which OS they run. So apps that Purism creates need to run on the largest possible installed base.

You can distribute flatpak packages without accepting them.

A foundational tenet of Free Software is to not exclude any field of endeavor, instead of imposing restrictions, it grants rights to other people, and one of those rights is to make any kind of application you like as long as you comply with the license. We cannot impose any restrictions on ‘external’ software, nor should we.

It’s not about restricting or preventing user to install external software by all means. It’s about
not promoting a technologie whose major goal is to ease the installation and proliferation of
external software (weakening maintainer curation). You should add flatpak in your repository
(sometimes this can be useful) but you should not promote it. Conversely, I’m not against
using this technologie to promote free software.

Portability is a foundational requirement for collaboration on applications, this is how you get Fedora developers interested in working on applications and libraries in Debian.

Ok, this argument is a good one but not enough for me. Let’s face it, you already share
your packages with Debian. All packages on main should be mostly ok without revision.
The remaining packets that you do not want to share with Debian is because you have
a different philosophy than Debian.

If, in the future, there is too much similitude with another distrib, you can just fusion
with this distribution.

Even with all these packages shared, do their are enough packages that other distribution
will want (as the other distributions by definition have other philosophies than PureOS and
so do not share globally the same packages than PureOS). And even if yes, does this really add
enough value to really worth all the drawbacks ? Serious question.


#36

Sincerely, I think that you will not stop using flatpak maybe because
I’m not persuasive enough :wink: So here, I will propose a mitigations to
the problem.

Be sure to sign every accepted packages by using an official Purism key.
If the package is not signed you should output a creepy warning (red banner,
a message like “this software has not been audit”, a link for more information
and all this stuff). The goal here is not to prevent the user to install something
external but to push the user inform himself before doing so. The link should
point to why using proprietary software is bad and why circumventing the
“curation” done by maintainers contain risks about freedom.

Also, You should add an option in the settings to add a developper key and
so to bypass this warning.


#37

What about appimage instead of flatpak ?

According to

It is possible to build armhf or arm64 AppImages based on Open source projects


#38

If those are indeed Linux apps that run anywhere, there should be nothing stopping people, in principle, from using that particular technology if they desire to do so. The Purism team seems to have settled on Flatpak for their store, and they aren’t stopping any of us from using any other distribution / package management solutions we prefer, so I don’t understand why anyone is trying so hard to get them to change their minds about something when they’ve already very patiently explained why they’re sticking with Flatpak and demonstrated that quite a bit of thought has already gone into their decision. If you don’t like Flatpak and prefer something else, use it. That’s the beauty of GNU/Linux.


#39

It is the intention to improve GNOME Software until it does what we need it to do. But Software is just a client, so we need to have an upstream repo to pull from.


#40
But even if you have a maintainer for your distro, it doesn’t mean that there is suddenly a layer of security, even if your distro is Debian.

It does however mean that the user can trust that the source corresponds to the binary, since the user gets the binary from the (already trusted) distro maintainer who compiles it from the source provided by the developer.

Yes, hopefully. This process you’re describing of a maintainer compiling source code into a binary package and then signing it is the ideal. With the addition of reproducible builds, which we have every intention of bringing into PureOS, that process will get stronger so that you can build an upstream PureOS (or Debian) package from upstream source on your machine and it is byte-for-byte identical.

How is this addressed in the flatpak/store model?

It is not addressed identically because the flatpak model is quite different. Packages, whether they are rpms or debs, are small, often only application specific sets of business logic. This means that they often rely on the underlying OS for dependencies. That also makes them dependent on a particular version of the dependency or OS. One way to address the issues around dependencies is to design a flatpak to run on any system that has some kind of access to a Linux API, either through containers or other means. This way you can be assured that at least the low level system calls to the Linux API will be there and you can fill in the rest with a runtime that supports your application.

Your question is how is the trust model built in flatpaks; the answer would be that it is largely the same, you rely on the maintainer but this time you’re relying on not just the maintainer of the application, but the maintainer or maintainers of the runtime as well. You can see some of the maintainers for the KDE runtime here: https://phabricator.kde.org/source/flatpak-kde-runtime/history/master/ Multiple maintainers means, in theory, that more bugs get caught.

In PureOS we intend to review every single app submitted to the apps store. Every. Single. One. The review will happen via tooling that does static analysis, checks for license, etc. Humans will also review, but the easier checks that already have sufficient tooling will be done automatically. Hopefully we’ll have extensive reporting on the apps as well because we have tools, like diffoscope, that can help us.

We are still in something of an evaluation phase, but we want to have an end-to-end app store available ASAP. That means you can view an app, select it, download it, and run on the devkit or other librem (a huge part of the store is to ensure that any store app can run on the phone or the laptop, or whatever device runs PureOS.)

PureOS also intends to have other security mechanisms that we’ll discuss as they come into place, one of them is intended to be a badge that shows that we’ve reviewed the app and it passes the basic security profile we require. The goal is to have a strong, highly secure means to convey apps to users easily.


#41

flatpak can run on ARM64 and x86, it currently runs on any architecture Debian runs on and likely can run on any architecture that runs Linux. Example: https://packages.debian.org/stretch/flatpak (See below in that link to see the architectures it runs on.)