Summary of the discussion about Filter Fedora Flatpaks Atomic Desktops v2 proposal

Project Discussion Change Proposals
, ,
21

We need to talk specifically about the value proposition of Fedora Flatpaks.

If we wanted to choose Fedora Flatpaks to be security-conscious.. that’s great. That could be its mission.. that mission has ecosystem wide impact beyond just Fedora.

Taking on that mission means certain things however. We can’t just claim it security minded, we need to build process and policy that makes it truer… including working more directly with the upstream portals development and making it a point to stop using flatpak static permissions overrides for the sake of a smooth user experience.

A no static permissions… portals only by default.. policy stance would be a drastically different value proposition and mission compared to flathub and something I could personally champion that has value ecosystem wide. That’s not its mission right now though.

22

Social or not, IMO the problem could be best solved technically. For Silverblue in particular, if users had the option to set the remote order preference in GNOME Initial Setup (for new installations) and GNOME Software (for later changes), there would probably be less opposing views in the community.

4 Likes
23

In the meeting yesterday we agreed to write what changes we’d like to write in the proposal. This is hard, because the goal is not criticize the existing one, or to write my own proposal, but to help establish boundaries and expectations for a good proposal. The discussion yesterday about accepting temporary degradations in quality helped me frame this.

yeah.

Problem statement: Fedora provides its own flatpak repo that overlaps with Flathub. Many users would prefer to use the Flathub flatpaks, but using the graphical environment they often end up installing the “wrong” version because Fedora is configured as the default remote.

I’m not sure this is the actual problem here.

It seems like it’s more that the fedora flatpaks default is causing
problems for users/atomic desktop maintainers, and the general feeling
is that making flathub flatpaks the default would reduce these problems.

I find it a bit difficult here though because these ‘problems’ are all
sort of difficult to quantify. Sure, there’s been examples here on
discussion and probibly in matrix rooms, but it’s hard to know how many
people are hitting issues and… what are they exactly?
I mean, switching from a fedora flatpak to a flathub one solves some
problem, but is it something we could fix in fedora flatpaks?

Goal: Avoid the situation where users install a version that doesn’t work for them. Provide enough information for users to make a choice, don’t force the choice on them.

I think this goal is laudable, but difficult.
Most people aren’t going to care about this choice, they just want the
working thing.

Assumptions:

  • Users want to have access to as many kind of flatpaks as possible, incl. stuff with codecs and other patent-encumbered stuff.
  • Some users care about a FOSS license, others do not. Similarly for other attributes like “built-from-source”, “verified”, “safe”.
  • I assume that users who have preferences might compromise in specific cases, e.g. if the flatpak is particularly important to them. For example, if I need org.telegram.desktop, I’m going to run the version that is available, even if it is not “verified”. OTOH, I might not download a game if it is not “verified”.
  • As a project, we’d like to make users aware when they a) install software that is not provided by Fedora, b) install software that is not FOSS, c) install software that has packaging shortcomings, i.e. old runtimes, is not built from source, is “unverified”. At the same time, we’d like to make it easy & convenient to gain access to such software. Ideally, through an obvious toggle.
  • As a project, we’d like to maintainer “federability” of flatpak, i.e. allow access to both popular Flathub, but also to our own remote.
  • If we change the defaults or remotes, existing installations should continue to be upgraded and should not require manual intervention.
  • User preferences should be maintained, so if a user installs from one remote, they shouldn’t be switched to a different one on upgrades, unless the old remote stops providing something.
  • We care about multiple architectures, at least amd64, arm64, and risc-v, and we want to provide flatpaks for all of them. (Possibly not now, but later.)
  • Flatpaks with EOL runtimes and other shortcomings are a real security issue.

Considering all this, I think the existing proposal might make various groups unhappy:

  • if we only offer verified_floss, a bunch of important flatpaks would be excluded, e.g. chrome, spotify, steam, vlc.
  • if we cut this even further to “built from source”, we make the problem worse.
  • OTOH, Fedora developers and security-conscious users might want to install the Fedora flatpaks without jumping through hoops.
  • In general, strict filtering is not great. A soft search result which says “there are more options, but your current policy excludes them. Click here to see more.” might be much more liked by users.

Dunno, after writing all this out, I feel more and more that this is a social and UI problem, not something to be solved at the technical level. Would it be an option to get some UI and UX designers to chime in, possibly suggesting some solutions how to make users happy?

So far they haven’t. :wink:

But this sort of thing is always really difficult in a UI…

user: I want to install $application
software: “$application is available from Fedora Flatpaks and Flathub,
click on each to read more about their history and background”
user: !

I think perhaps another way to approach this problem would be to try and
fix those issues that are causing this desire to make flathub default.
Sure, there’s some applications where the problems are legal / codecs
and there’s not much we can do, but are there other cases?

Perhaps a shorter term thing we could do here is formalize bugs/issues
around fedora flatpaks. Right now they get assigned to the rpm packages
or just mentioned on discussion/matrix and so there’s no clear history
of whats actually not working and why. We could create a central place
on forge for them or add something to bugzilla.

Longer term, I’ll toss out an idea I had a while back:

  • Take the list of all currently existing fedora flatpaks
  • subtract out those flatpaks that are installed on images.
  • Find the maintainers of the rpm version of each application.
  • File a bug for each saying:

"Hey, we have this Fedora Flatpak of your application.

Can you take a look at it, consult with your upstream
and whoever else and decide if this flatpak is good to
keep shipping? If it is, we will assign it to you."

  • Set a deadline (f46 branching?). applications where maintainers
    have not responded at all, or where they reply that the fedora flatpak
    is not desired are dropped. There could be an additional step here
    for others to step in where maintainers say they only have time/desire
    to maintain the rpm(s).

That would at least spread out the maint burden for flatpaks.
The flatpak sig could still maintain runtimes, help maintainers with
their flatpaks and coordinate things.

24

tl;dr: I think the premise that “Fedora Flatpaks are inferior” is incomplete/faulty and that making our decisions from that starting point leads to incomplete solutions. I suggest some compromises both packages might make in order to work closer together.

Revising the problem

Problem statement: Fedora provides its own flatpak repo that overlaps with Flathub. Many users would prefer to use the Flathub flatpaks, but using the graphical environment they often end up installing the “wrong” version because Fedora is configured as the default remote.

I think the problem statement is not entirely correct, which has the unfortunate effect of making everything that comes after it subtly incorrect as well. Let me try to restate it:

Problem statement: Fedora provides its own flatpak repo that overlaps with Flathub. Users want to run applications on their system that behave in the manner they expect from it. Some Fedora flatpaks do not meet this expectation satisfactorily while the associated Flathub flatpak does. Using the graphical environment they often end up installing the “impaired” version because Fedora is configured as the default remote.

Zbigniew’s problem statement makes the assumption that the Fedora flatpak is inherently “wrong” from the users’ perspectives. For some of the Fedora flatpaks, this is because what Fedora is shipping does not meet the users’ expectations (often because of legal or philosophical limitations). For other flatpaks, it’s due to simple packaging mistakes exacerbated by an extremely under-resourced Flatpak SIG. There is certainly an argument to be made that if the Fedora flatpaks were able to deliver the same level of functionality as Flathub, users would neither notice nor care where they were delivered from.

There are two main constituencies that are butting heads here, and they’re hardly new; application developers and system integrators have always pushed against one another in Fedora. Application developers want users to have the exact experience that they are building for them and they get frustrated when external forces (such as OS libraries not being at the same version as their development userspace or lacking functionality on one platform that is available on others). For these people, consistent behavior is the most important thing. They don’t want to try to debug their applications in all of the possible nigh-infinite combinations that distro packaging entails.

System integrators on the other hand are more risk-averse; they’ve been through the proverbial war and have been burned in the past. They prefer distribution packaging because it generally means that things will be updated and maintained in the event of a security issue or other critical bug as well as providing some assurance that the application being delivered was actually built from the published sources. The major limitation here is that they’re bound by the philosophical and legal limitations of the distribution hosting their application. Fedora is stricter than most others and that means that an application running strictly from Fedora-built content can sometimes be “crippled” from the user’s perspective.

How does Fedora improve the situation?

Let’s see if we can itemize the desired outcomes

  1. Users want applications that work in the manner that is described by their upstreams.
  2. System integrators want assurance that the application was built in a trusted environment.
  3. Application developers do not want platform-specific bug reports that they cannot act on.
  4. The Fedora Project wants to be able to ship some Flatpaks on install media.

Users want applications that work in the manner that is described by their upstreams.

This is often disconnected because Fedora’s RPM package updates tend to move at a different pace than most upstream applications can keep up with. As a result, Fedora Flatpak creators may need to do significant integration work such as patching the code to work with newer libraries.

Could we (Fedora) we allow more bundling in the Fedora Flatpaks (with appropriate reporting and warnings in the GUI about risky, out-of-date content)?

System integrators want assurance that the application was built in a trusted environment.

When people install Fedora, they are making a decision to trust the Fedora Project about the content installed on their system. We make a lot of public statements regarding our policies around shipping only open-source software that we build ourselves in our trusted buildsystem.

Could Flathub possibly make the buildsystem a modular environment where distributions could rebuild the content according to the flatpak “recipe”, so that (so long as it was legally permissible) we could ship a Fedora rebuild that is guaranteed to have been built in (and signed by) our infrastructure? These built flatpaks could be distributed by Fedora, Flathub
or both. This might require some work to revise the current setup where flatpaks “own” unique application names. I don’t have an answer for that currently.

Application developers do not want platform-specific bug reports that they cannot act on.

I think if we managed both of the above suggestions, the number of platform-exclusive bug reports would decline significantly.

The Fedora Project wants to be able to ship some Flatpaks on install media.

As long as Fedora-built flatpaks can be built, we can find a way to accomplish this.

CC @jspaleta

1 Like
25

Perhaps instead of focusing so much on exposing remote selection it would be more useful focus on exposing a set of features/capabilities per app/remote pair

I think users will not care if they are installing an app from Flathub or Fedora but they may care if one of the options has “proprietary media compatibility” for example.

It seems right now we are using the remote as proxy to derive this kind of information about the applications. (“if Firefox comes from Flathub then it will support proprietary media”)

we could cut that step and just offer the user to the options to install “Firefox (proprietary media support)” and “Firefox (built by Fedora, FOSS only)”

Maybe this information could be part of the appstream metadata or something similar and consumed by gnome software/KDE discover

26

Hmm

I keep thinking a lot about pypi and why we aren’t spinning up a Fedora repository that complies with PEP 503 as a default source for the pip we ship that translates all the python packages we ship as RPMS back into wheels to meet the expectation that all binaries users install via tools we distribute are built from our infrastructure.

We’ve had access to pip now for a little longer than flatpak, pip was introduced in Fedora back in 2015. And in all that time, the project has never collectively chosen to override that pip platform’s default installation source with something that guarantees a Fedora Project infrastructure build of the wheel format binaries pip is able to grab.

But we could, in fact I’ve had real discussions with people face to face about that possibility because of the security value-add of what that registry would provide. But there is no way it would be appropriate to turn that on by default in all of this project’s outputs as a replacement for pypi because it would break user expectations in significant ways. It would have to be positioned as a security value add in a targeted way.

Thinking about pip… makes me think about… rubygem, nodejs… these tools that you can install from Fedora that subsequently pull ‘packages’ sometimes with pre-compiled executables from outside of the Fedora build system from centralized locations. We could choose to repackage rpms into all their native tool formats and produce an alternative registry and enable our versions of those sources. But we don’t. We could do it for exactly the same reasons, and it would break default user expectations to do it.

if anything flatpak is the platform that is treated as an outlier compared to pretty much everything else. Everywhere else I look inside the Fedora repository and I find a tool that intends to be a base OS agnostic way for upstream project developers to interface with users, I see we are allowing that relationship to exist without imposing this policy interpretation that this needs to be built on fedora infra. We take a much stronger upstream first approach to pretty much all platforms except for flatpaks. And I think … as a matter of policy… we hold flatpak to standard that doesn’t apply to other platforms that we ship tools for when it comes to how we regard the trustworthiness of the defacto upstream repositories. And what is crazy to me is flatpak because its attempting to provide a sandbox implementation is probably the one platform we should be willing to trust more than the other platforms we ship the distribution tools for, and not the other way around.

My point is for all these things.. for all the base OS agnostic platforms that we ship client tools for , it may not be appropriate to enforce the ideal that Fedora content should replace the default centralized upstream community content, because by doing so we break a user expectation implicit in the platforms. For these base OS agnostic platforms, It may be most appropriate to position Fedora content as a more secure value-add that users choose to enable, because the users who choose to enable a Fedora hosted pip, gem, flatpak, or npm registry are going to have different expectations on behavior than that the default registries for that platform. And those users who value the security of Fedora as layered platform content, are going to be spread out across the wider ecosystem.

For better or for worse, Flathub is to flatpak as pypi is to pip… even if we were to spin up a Fedora pypi to serve up wheels reconstructed from rpms.. I very much doubt that we would as a matter of policy disable pypi by default and replace it with our PEP 503 compliant registry. That would cause a huge problem because it would not meet user expectation with how the tool worked in the median case. But we could offer it as an alternative, and target it for use in specific outputs.

1 Like
27

This, but also built-from-source, FWIW, is the bare minimum I would vote for to be enabled out of the box, even for Atomic spins that opt in. Users should still be asked before enabling any larger subset of Flathub. And I note that as of last week verified_floss has… 19 applications, and we don’t have a tag for build-from-source yet.

+1 on zbyszek’s observation that we care about at least arm64 and maybe riscv64 in addition to x86_64/amd64 too.

It feels like putting the cart before the horse – we’re not trying to dictate to upstream, but we do have our standards to uphold. Perhaps we should pursue a two-pronged approach - while upstream Flathub work on this we can figure out a better ownership situation for Fedora flatpaks, as nirik suggested.

That might require accounts system changes and/or the Forgejo migration, given right now packaging bugs are tracked in Bugzilla and FAS only recognizes two default assignee (Fedora and EPEL)

1 Like
28

If the compare and constrast of flatpak/flathub with pip/pypi isn’t sufficient…

I can do a compare and contrast with how we currently handle podman container registries

we ship podman with fedora, redhat.com and docker.io registeries enabled by default via the container-commons package, which maps to https://github.com/containers/container-libs

Only one of those is a registry that maps to binary outputs that come from the fedora infrastructure that match the concept that everything presented to Fedora users needs to conform to project ideals of being buildable from source from our infrastructure.

What’s even crazier is we patch the upstream config with a shortname aliases for a few important things that help ensure Fedora users get what we consider are the official versions of those common things from docker.io and not from our infrastructure. In fact the only thing in the shortlist that enforces the fedora registry is for containers for obviously fedora outputs

 "fedora-bootc" = "registry.fedoraproject.org/fedora-bootc"
  "fedora-minimal" = "registry.fedoraproject.org/fedora-minimal"
  "fedora" = "registry.fedoraproject.org/fedora"

That’s it.. thats the only thing in the short list that refers to fedora.

For example… lets look at rust.

$ podman search rust --limit 10
NAME                                 DESCRIPTION
registry.fedoraproject.org/f41/rust  
registry.fedoraproject.org/f42/rust  
registry.fedoraproject.org/f43/rust  
docker.io/library/rust               Rust is a systems programming language focus...
docker.io/cimg/rust                  The CircleCI Rust Docker Convenience Image.
docker.io/circleci/rust              CircleCI images for Rust
docker.io/okteto/rust                
docker.io/bitnami/rust               Bitnami Secure Image for rust
docker.io/chainguard/rust            Build, ship and run secure software with Cha...
docker.io/stagex/rust                Rust Programming Language toolchain
docker.io/primeimages/rust           Alpine with Rust installed
docker.io/activestate/rust           ActiveState's customizable, low-to-no vulner...
docker.io/ubuntu/rust                Rock for Rust - a systems programming langua...

Fedora provides a rust container so does docker.io. Docker.io provides a ton of options..
Which one is official?

$ podman search rust --filter=is-official
NAME                    DESCRIPTION
docker.io/library/rust  Rust is a systems programming language focus...

Now what if we just pull rust? What happens? Well thanks to the shortname alias we package… its not the fedora rust container that is preferred.. its a specific docker.io one.

$ podman pull rust
Resolved "rust" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/rust:latest...

This is the exact opposite of how we treat official things in the flatpak platform. I don’t need to get into the discussion of the opinionated graphical UI tools, I run into the very different default policy stances in the cmdline tools.

If I wanted to find “the official” postgres container in podman.. I run this:

$ podman search postgresl --limit 200 --filter=is-official
NAME                        DESCRIPTION
docker.io/library/postgres  The PostgreSQL object-relational database sy...

But because we don’t shortname alias postgresl (though we probably should) podman pull gives me an interactive choice…

$ podman pull postgresl
? Please select an image: 
  ▸ registry.fedoraproject.org/postgresl:latest
    registry.access.redhat.com/postgresl:latest
    docker.io/library/postgresl:latest

giving in the order of the default searchable registries.

Here again flatpak as a base OS agnostic platform is being treated differently than a peer technology (in this case the peer technology is podman) If we treated flatpak as we do podman.. not only would be enable flathub by default.. but we would ensure that official upstream flathub versions of things were preferred over the fedora project outputs when we know they are official upstream outputs.

It appears that flatpak is being singled out as a platform technology in a materially different way than other platform technology that Fedora ships tools for. Continuing to enforce a strict preference for Fedora flatpaks over defacto upstream platform content registries appears to be a unique policy interpretation that is not applied to any other platform tools Fedora ships.
There is a list of these things now: podman, pip, gem, npm, and I would imagine nix as well if I were to look…all come with external registries by default that have user installable binaries from build systems Fedora does not control… and users expect these registeries to be used as part of using the tooling.

To remove a defacto standard platform registry is outside normal practice inside this project. And yet that is what we are doing for flatpaks. The idea that somehow flathub is less trustable than docker.io or registry.npmjs.org is very hard for me make sense of. And to be very honest if feels to me like goal post shifting specifically applied to flatpaks and nothing else. I can’t square the circle here. There is a pattern of practice that strongly suggests that standard project policy is to rely on defacto platform registries. I fail to see why flatpak/flathub is any different than podman/docker.io

3 Likes
29

I was actually thinking about the Nix change proposal the last week when I saw this in being discussed in the FESco meeting and was wondering if we having a bit of double standards here when it comes to third party packages.

1 Like
30

To me, I think there are two major differences

  1. pip, gem, and npm, and somewhat Nix are developer focused tools. If you want to install software with them, you use the CLI. Those who use this external repos are more likely to recognize that this software is not provided or endorsed by Fedora. The tools are on the system, but the user is essentially opting in to use them. Whereas with the Flathub discussion, it’s a user facing change: the GUI stores (Gnome Software, Discover, etc) will automatically expose the new apps provided by Flathub and would prefer these third party packages over Fedora packages.
  2. To reiterate something I said earlier, it’s strange that Fedora would build these Fedora Flatpaks, only to then hide them from the user in favor of Flathub packages unless the user went out of their way to enable the full Fedora Flatpaks repo.
    • Fedora should not hide its own outputs. It should either fully endorse them or stop building those outputs in the first place.
    • The main criticism of Fedora Flatpaks is that they are lower quality and users expect to have upstream supported packages.
      • But the lower quality is generally not a problem with the flatpak, but with the underlying rpms. So either the rpms should be fixed or Fedora should stop providing those rpms.
      • And for the “users expect upstream packages”, similar deal, either the user should know/be informed that Fedora packages are not supported by upstream, or Fedora should stop providing rpms and flatpaks for software that has upstream supported versions. Not a weird middle ground where Fedora rpms are treated as fine but Fedora Flatpaks are treated as a problem.

Even as someone who likes Fedora Flatpaks and would like for it to be improved and embraced, I would rather have them forcibly[1] killed off (except for the ones needed by the base system for legal/practical reasons) rather than have this convoluted scenario in which Fedora builds a whole bunch of supposedly “low quality” Fedora Flatpaks that they then hide away in favor of Flathub packages but at the same time keeps the “low quality” RPMs for the non-Atomic distros.

In other words, I would prefer one of these options

  • Fedora embraces its role as a distributor: Keep Fedora Flatpaks and RPMs and always recommend them over Flathub
  • Fedora embraces upstream packaging: Keep Fedora Flatpaks but only those necessary for the base system and discontinues Fedora Flatpaks and RPMs that are “obsoleted” by official upstream packaging

  1. I specify forcibly because of Fedora’s governance is complex and the Fedora Flatpak SIG can’t really be compelled to stop producing Fedora Flatpaks, except by FESCO, which is part of the reason why there proposals try to work around that by only hiding them instead. At least, that’s my understanding of the situation ↩︎

1 Like
31

Well, for at least Podman, Fedora is not generally aware of how the containers/shortnames project is managed and this has generally slipped by. I would be happy to consider stripping shortnames in Fedora if we want to do that.

For the other tools, they are not installed by default, they aren’t typical for user workflows, and we aren’t actively promoting them. And to be honest, most of those tools are optional for actually leveraging stuff for developing in their associated languages. I don’t use pip for Python development at all. I use only the RPM packages in Fedora. Missing modules get packaged by me as needed.

This has come up before with another technology: Snap. The reason snap has made no actual progress in Fedora is because of all these problems. That is despite Snap being a broader technology, having more flexibility, and being designed as a more appealing stack for sandboxed applications (it supports more application architecture models than Flatpak does).

Flatpak was explicitly promoted because Fedora can provide its own outputs, it can promote them, and we can express our opinions for application delivery through it.

I am not in favor of any dark pattern that allows any Fedora deliverable to hide outputs from Fedora to promote externally delivered ones.

3 Likes
32

I disagree.

I look at it this way, we created the expectation problem by standing up a registry and turning it on by default in such a way that it directly conflicts with upstream platform intent. If we hadn’t taken that action, flatpak would just be another platform with an external centralized upstream distribution in the form of flathub and we’d be enabling it by default. This project made a choice to conflict. We could have choosen to stick with rpms as the fully integrated application solution and found a way to make it work even for image mode deliverables, overlays are thing.. dnf will be able to create image overlays to install additional rpms… there is no reason not to expect dnf plugins for application stores that allow rpms to be installed won’t be able to find a way to use the overlays. Spinning up a conflicting flatpak registriy wasn’t the only technical path forward.

What do I mean by conflict? Unlike podman and OCI registries, flatpak doesn’t allow you to install the same thing from different registries side-by-side… its not fully federated.
I can with podman or podman desktop pull for example multiple variants of postgresql. This is a fully federated system.

Instead flatpak assumes that you will only have a single variant of the same application id installed on the system at any one time. That is only partially federated, and by standing up a flatpak registry that conflicts with the contents of the flathub verified floss subset, we’ve created a significant conflict in user expectation in the context of how the partially federated platform works.

Imagine a world where everything we shipped in our Fedora Flatpaks was a verified upstream flatpak and this project was the upstream for. In that world it would be clear which application IDs were Fedora owned because we’d be able to make use of the org.fedoraproject prefix for every flatpak application we chose to package from our build system. Absolutely cyrstal clear identification as to where the bug reports go because we would take ownership by making use of the application id prefix and users would be able to install the verified upstream and the Fedora variant side-by-side.

But that’s not what we have. Because now its assumed that its nigh impossible to actually use the application ID prefix we own as a project in this way. And this is where this project probably made its mistake, not realizing how choosing not to solve the problems that make it impossible for us to make use of the org.fedoraproject prefix as a way to deconflict applications.

It should be noted that Runtimes and Extensions arent a problem.. we actually don’t conflict with any upstream on these crucial parts of the flatpak ecosystem. We make use of the org.fedoraproject prefix for these things and we could redistribute those bits in flathub right now…assuming we met their policy for inclusion… and we could probably get veriflied floss subset inclusion for those things. its the application builds where we conflict. We can’t seem to find a way to make use of the org.fedoraproject prefix that is recognized that we own. That’s us making a mistake.

In that ideal worled we could even cross-distribute the application builds we produce into flathub as a secondary distribution channel. We wouldn’t even need our own flatpak remote.. our builds are just a filterable part of the FlatHub collection in that ideal world. We could even pre-install from that namespace at flathub because that filteredable subcollection would meet our legal requirements…if we had found a way to use the org.fedoraproject prefix for every flatpak that comes out of the fedora infrastructure.

Hindsight is 20/20, we should have made the necessary technical changes to the platform that make it possible for us to use the application-id prefix we obstensibly own so we could be the verified upstream for everything we put into our flatpak remote before we spun up a flatpak remote. We chose to be in conflict with upstreams by jumping the gun and coloring outside the lines with regard to platform intent. We should want to be the verified upstream for all all things we output so they do not conflict with other verified upstreams using the platform.

Now we’re stuck… because we took a shortcut and aliened rpms into flatpaks without fully understanding the intent of how the platform is meant to work as a federated environment. We caused the conflict.

1 Like
33

I think you missed the actual mistake that made this break down. It wasn’t RDNN (though I do personally consider it a mistake for other reasons), it was that Flatpak doesn’t expose or use fully qualified URIs like other things do.

There is no reason that fedora/<app-id> or flathub/<app-id> shouldn’t be the fully qualified path for everything in all interfaces, as well as on-disk. It’s even possible to fix it today if anyone cared to. Incidentally, this is basically how it works for Snap. Snap “tracks” are parallel installable and usable, as everything connected to the host is exported namespaced. They can be used simultaneously.

But it isn’t going to happen because nobody is actively pushing for these interfaces to change. Instead we’re getting stuff like this Change, which attempt to weaken the need to fix it.

2 Likes
34

I’m not sure this can be implemented (and thus provide the required flexibility) without also adding complexity in usage.

I feel that being able to install the same Flatpak app from multiple sources at the same time is something only a small fraction of users would find beneficial. The others would prefer IMO to uninstall an app from remote-A for instance and (re)install it from remote-B, while keeping the previous user configuration, without the need to copy config files from one local path to the other. But I miss real data, so I might be wrong here.

1 Like
35

When worded like that - isn’t that a security concern?

If I convince you to remove your Firefox and install org.mozilla.Firefox from my remote - will I be able to upload your cookies somewhere?

Maybe it is a far fetched attack but I could also think of an example where com.myApp from remote A offers v1 and com.myApp from remote B offers v2 and if there is an incompatible data schema then changing between them will not work.

It seems data should not be shared between different remotes. I can think of Android where f-droid applications don’t have access to data from their playstore counterparts due to different appid.

I would agree with the perspective that Fedora should only publish under their namespace OR the remote should be part of the namespace itself

In either case I still think exposing “fedora/firefox” vs “flathub/firefox” would be quite opaque to someone who doesn’t already know what flathub is

36

There are practical reasons to do so even if you take Fedora Flatpaks out of the picture. Right now, it’s pretty difficult to simultaneously test “stable” and “unstable”/”pre-release”/”testing” versions of Flatpak software simultaneously from the different Flathub remotes. And some projects go so far as to add an application ID suffix to try to approximate the snap “track” feature on Flatpak.

And implicitly, Flatpak already locks installed flatpaks to the remote they were installed from, so the mechanism is there, it’s just not consistently applied or exposed. User data and desktop file exports should encode this somehow, but they don’t.

2 Likes
37

Yes. But owning our own outputs doesn’t mean we must choose to conflict with upstream outputs.
In flatpak.. even without extending the namespacing to include registry name… we don’t have conflict… the flatpak’s concept of application id prefixes work for the runtimes and the extensions… but we made a mistake with the applications and we are serving applications that conflict. We could choose to treat the Fedora outputs as hard forks and take ownership and stand behind them as the verified upstreams. Doing that is a policy choice in how we operate our flatpak remote. We can choose to deconflict and advertise the flatpaks as hard forks of applications as a matter of policy.

The fact that we aren’t choosing to build flatpaks like org.fedoraproject.Mines is the conflict.
Noone disputes that we own that prefix in the flatpak sense. We should own that prefix and we should be able to populate that prefix with our application builds in a such a way that its non confusing to users when there are verified upstreams producing their own flatpaks via a remote. We can then choose to distribute them from our own infrastructure (which is what we’d likely need to do for anything pre-installed) or we can choose to distribute them via additional remotes assuming our builds meet acceptance criteria..all the time being marked as verified because we are the recognized owner of the prefix.

38

I know this has been mentioned before but I don’t really think Flathub should be considered “upstream”.

Flathub is a flatpak distribution platform. It feels a bit strange to consider it upstream of Fedora.

1 Like
39

Verified upstream is a thing Flathub does… Flathub has a policy that establishes ownership of a prefix.

Verified floss is a particular subset of note because is where we have a conflict with upstream open source projects making use of Flathub as a way to access the entire linux desktop ecosystem as a single platform.

For example… podman desktop is in the verified floss subset of Flathub.
Which means that Flathub and the owners of of the podman-desktop.io domain have made some effort to establish that the people publishing to the io.podman_desktop prefix have the authority to do so.

Now we don’t have podman desktop yet at all in Fedora, primarily because we can’t seem to figure out how to deal with the challenges inherent in the bundling that electron based apps need. And if anything, everything about podman desktop as a flatpak right now screams security nightmare because of the way it punches holes in the sandbox to do the work it does… but i digress. Regardless of the concerns I have about it, its an expression of upstream intent to deliver something to users across the entirely linux desktop ecosystem (and beyond into WSL2 environments when flatpak can be made to work there) if we started producing a Fedora flatpak of the podman desktop application we would be in direct conflict with the upstream’s intent to delivery a common experience across the entire addressable linux desktop ecosystem.

So no its more complicated than just another peer distribution. There are aspects that are, but there are aspects that put us in direct conflict with upstream outputs. Now in many circumstances in the verified_floss we may find the ouputs of subjective quality and security… but that doesn’t change the fact that what we find in the verified_floss subset is an expression of upstream intent and best effort. And flatpak if its anything is intended to give upstreams the ability to address the entire linux desktop ecosystem( including WSL2!). I would love nothing more than for this project to stand up remote that was in coopetition with flathub, and was attractive for upstreams to target as a distribution channel that focused on security and quality in more concrete ways. but that’s not the flatpak remote we have right now…and its sort of a missed opportunity really to engage with upstreams. Until we have a process that invites upstreams to choose to be verified outputs in our flatpak remote.. we’re missing an opportunity to material impact what the flatpak platform is meant to achieve. But that’s more about defining a mission for what we are doing that ties everyone back together to move the ball forward on what flatpak as a federatd technology can become.

40

If I end up installing an app with security vulnerabilities, I am already in trouble, regardless of whether there is leftover user data or not.

There is always the option to delete user data when uninstalling a Flatpak app. GNOME Software asks the user about keeping/deleting data at uninstall time.

Publishing under different namespaces would lead to less than stellar UX IMO, at least with the current implementation of the software managers. See for example Thunderbird, which has two app ids (net.thunderbird.Thunderbird from Fedora, and then org.mozilla.Thunderbird from Flathub, as well as from Fedora as EOL). Now if you go to GNOME Software and search for the keyword “Thunderbird”, your search result will prompt two Thunderbird entries, with no hint which is which.

GNOME-Nightly handles this pretty well, at least for testing purposes. Most refs receive a “.Devel” suffix, with Epiphany also having an unstable version, in addition to the devel one:

$ flatpak search org.gnome.Epiphany
Name      Description         Application ID                 Version      Branch      Remotes
Web       Browse the web      org.gnome.Epiphany.Devel       50.0         master      gnome-nightly
Web       Browse the web      org.gnome.Epiphany.Canary      50.0         master      gnome-nightly
Web       Browse the web      org.gnome.Epiphany             49.2         stable      fedora,flathub

The apps also get a nice “under construction” overlay on their desktop icons.