This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
The flatpak remote for Flathub will have no filtering, making all the Flathub content available in GNOME Software and via the flatpak commandline.
== Owner ==
* Name: Workstation WG * Email: mclasen@redhat.com
== Detailed Description ==
Fedora includes a flatpak repo definition for Flathub in the fedora-flathub-remote package. So far, this remote was filtered by an allowlist that only made a limited subset of software from Flathub available. We've been told that it is ok for us to remove the filtering and make all of Flathub available.
The filtering mechanism itself will still be there, and it will be possible for us to reinstate a filter via a package update, should the need arise in the future.
The Flathub remote is available to users who opt-in to enabling third-party software repositories in either GNOME Initial Setup or GNOME Software. Users who do not opt in will not see anything from Flathub.
In case of overlaps, GNOME Software will prefer Fedora flatpaks over Flathub flatpaks. It is always possible for the user to manually select a different source for individual applications.
== Feedback ==
This change proposal has previously been discussed here: https://pagure.io/fedora-workstation/issue/300
== Benefit to Fedora ==
More software will be easily available to Fedora users.
Additionally, the filtered Flathub has not been popular with users. Users have been confused and displeased that our Flathub remote contains only a small subset of Flathub, rather than the full Flathub. Dropping the filter will resolve this criticism.
== Scope ==
* Proposal owners: Remove the allowlist in /usr/share/flatpak/fedora-flathub.filter, or replace it with one that allows everything * Other developers: GNOME Software developers: Verify that the priorities between repos and packaging formats work out as desired * Release engineering: No work needed * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives:
== Upgrade/compatibility impact ==
Existing Fedora installations with a configured Fedora Flathub remote will pick up the new, permissive filter.
== How To Test ==
When third-party software is not enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should not appear in GNOME Software. When third-party software is enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should appear.
== User Experience ==
When opening GNOME Software, all the applications that are available on Flathub will show up in search results.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: Reinstate the filtering we had in Fedora 36 * Contingency deadline: Beta * Blocks release? No
== Documentation ==
* [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md fedora-third-party] * [https://github.com/flathub/flathub/wiki Flathub wiki] * [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remotes... Comparison of Fedora Flatpaks and Flathub remotes]
== Release Notes ==
The Fedora Flathub remote now exposes all content from Flathub, instead of only a small subset. Flathub is not enabled by default. To enable software from Flathub, turn on third-party software in GNOME Initial Setup or GNOME Software.
On 29/06/2022 19:34, Vipul Siddharth wrote:
The flatpak remote for Flathub will have no filtering, making all the Flathub content available in GNOME Software and via the flatpak commandline.
Strongly -1, because Flatpaks have higher priority over RPMs in Gnome Software.
1. GNOME Software need to be patched to prefer RPMs over Flatpaks for non-ostree Fedora variants, because it will replace Fedora packages with Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM" for Silverblue/Kinoite will be better.
2. Fedora shouldn't rely on low-quality third-party repository. A lot of Flathub packages even doesn't built from sources on trusted infra: Firefox, OBS Studio, Blender, Element, Signal, etc. They just repackage DEBs or static binaries:
- https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.y... - https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L98-L1... - https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blend...
Firefox and OBS Studio even uploaded as a pre-built ostree blob.
3. "Sandboxing" is the biggest lie. A lot of apps have --filesystem={home,host} in manifests:
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code - https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
- GNOME Software need to be patched to prefer RPMs over Flatpaks for
non-ostree Fedora variants, because it will replace Fedora packages with Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM" for Silverblue/Kinoite will be better.
GNOME Software already has a hidden setting for this:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/0709681441daf6b182a062d...
It defaults to Flatpaks because they are sandboxed and are much safer than unsandboxed applications.
However, I believe Flatpaks built from Fedora RPMs should take precedence over Flatpaks built from Flathub. Flathub should only be preferred when there is no Fedora Flatpak available.
Michael
On 29/06/2022 20:25, Michael Catanzaro wrote:
GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree Fedora variants (Workstation, Spins).
When the Flathub filtering is removed, most Fedora packages will be silently replaced by Flatpaks, some of them very low quality (DEB rebuids) because the Flathub versions are always greater than in Fedora.
It defaults to Flatpaks because they are sandboxed and are much safer than unsandboxed applications.
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code - https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
However, I believe Flatpaks built from Fedora RPMs should take precedence over Flatpaks built from Flathub.
Fedora Flatpaks are almost dead. Let's check this page: https://bodhi.fedoraproject.org/releases/
Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks). Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks). Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).
Flathub should only be preferred when there is no Fedora Flatpak available.
I don't see it in the proposal.
On Wed, 2022-06-29 at 20:41 +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree Fedora variants (Workstation, Spins).
Flatpak should come first as that what will be used in the long term.
When the Flathub filtering is removed, most Fedora packages will be silently replaced by Flatpaks, some of them very low quality (DEB rebuids) because the Flathub versions are always greater than in Fedora.
It defaults to Flatpaks because they are sandboxed and are much safer than unsandboxed applications.
https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
However, I believe Flatpaks built from Fedora RPMs should take precedence over Flatpaks built from Flathub.
Fedora Flatpaks are almost dead. Let's check this page: https://bodhi.fedoraproject.org/releases/
Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks). Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks). Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).
Can we investigate why is the case, its not like the packages in the repo cannot be package as flatpak. We could be crafty here as we can control extensions too (and can patch application if needed). I mean fedora silverblue 36 was shipping with gnome 41 apps on release. Maybe have fedora flatpak for certain popular applications(which can be flatpaked) as a blocker for this proposal.
Flathub should only be preferred when there is no Fedora Flatpak available.
I don't see it in the proposal.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org)
Thanks & Regards, Marc Pervaz Boocha
On 30/06/2022 09:52, Marc Pervaz Boocha via devel wrote:
Flatpak should come first as that what will be used in the long term.
RPM is the main packaging format for Fedora.
Can we investigate why is the case, its not like the packages in the repo cannot be package as flatpak.
Fedora Flatpak packages are hack-built from RPM modules.
On Thursday, 30 June 2022 at 09:52, Marc Pervaz Boocha via devel wrote:
On Wed, 2022-06-29 at 20:41 +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree Fedora variants (Workstation, Spins).
Flatpak should come first as that what will be used in the long term.
That's not true for all editions. I guess you mean GNOME/Workstation here. I'm not the only one here who's convinced that flatpaks are the wrong way to package software, so please don't assume whatever the Workstation WG is doing with flatpaks will be picked up by other editions.
Regards, Dominik
On Wed, Jun 29, 2022 at 08:41:51PM +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree Fedora variants (Workstation, Spins).
When the Flathub filtering is removed, most Fedora packages will be silently replaced by Flatpaks, some of them very low quality (DEB rebuids) because the Flathub versions are always greater than in Fedora.
It defaults to Flatpaks because they are sandboxed and are much safer than unsandboxed applications.
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code
However, I believe Flatpaks built from Fedora RPMs should take precedence over Flatpaks built from Flathub.
Fedora Flatpaks are almost dead. Let's check this page: https://bodhi.fedoraproject.org/releases/
Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).
^^^^ The link above says '3' for F36 Flatpaks
Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks). Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).
Comparing the raw number of RPMs v Flatpaks is not very relevant, because the count for RPMs includes every single library, cli tool, graphical app, whatever, while Flatpaks only count the graphical apps, not the building blocks they comprise.
Better to compare Flatpaks to the number of RPMs containing a .desktop file. None the less, I expect it would still show that Flatpaks are the minority of Fedora deliverables.
With regards, Daniel
Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:25, Michael Catanzaro wrote:
GNOME Software already has a hidden setting for this:
Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree Fedora variants (Workstation, Spins).
+1. Native packages ought to be preferred over random repackaged binaries from untrusted infrastructure (see the links posted by Vitaly for proof).
Users of RPM-based variants will expect the default package manager to install RPMs, not Flatpaks, or they would have chosen a Flatpak-based variant.
Kevin Kofler
Users of RPM-based variants will expect the default package manager to install RPMs, not Flatpaks, or they would have chosen a Flatpak-based variant.
Agree on that one.
That being said, what about allowing users to set this preference by themselves?
I also think that the repository information should also be made more visible; if a package is available from multiple sources, gnome-software will display a separate search entry for each of those, which looks very odd from a UX perspective - I'd expect some kind of match-by-id to be performed and for duplicated packages to either be merged into a single button, or to have some additional bit of text on them telling me which one comes from where.
Btw, shouldn't gnome-sofware pull in PackageKit? I typically only use dnf, so I installed gnome-software and it was unusable until I manually installed PackageKit as well.
A.FI.
On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
That being said, what about allowing users to set this preference by themselves?
+1. Let's let users make choices, not choose for them.
Gnome Software should explicitly ask the user to select a package source before starting installation.
On Thu, Jun 30, 2022 at 12:42:07PM +0200, Vitaly Zaitsev via devel wrote:
On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
That being said, what about allowing users to set this preference by themselves?
+1. Let's let users make choices, not choose for them.
Gnome Software should explicitly ask the user to select a package source before starting installation.
"Explicitly" is maybe too much. I'd imagine a single slider (or drop-down menu or whatever) that says "rpm", "flatpak from flathub", "flatpak from …" when there's more than one choice, with the default selected by the global preference.
Zbyszek
On Thu, Jun 30, 2022 at 8:11 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Jun 30, 2022 at 12:42:07PM +0200, Vitaly Zaitsev via devel wrote:
On 30/06/2022 12:33, Artur Frenszek-Iwicki wrote:
That being said, what about allowing users to set this preference by themselves?
+1. Let's let users make choices, not choose for them.
Gnome Software should explicitly ask the user to select a package source before starting installation.
"Explicitly" is maybe too much. I'd imagine a single slider (or drop-down menu or whatever) that says "rpm", "flatpak from flathub", "flatpak from …" when there's more than one choice, with the default selected by the global preference.
I want GNOME Software to prefer Fedora sources before third party ones. For me, I also would prefer RPM > Flatpak, because I don't like the experience I've had with Flatpaks and Flathub, but that's a different preference.
GNOME Software should always offer Fedora content first, because it's first-party. If a Fedora RPM and a Flathub Flatpak are on the table, it should prefer to offer the Fedora RPM.
GNOME Software should not be implicitly discouraging the Fedora community's efforts.
Keep in mind the alternative to people packaging RPMs isn't that they do something else, it's that they stop contributing entirely.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 30/06/2022 14:18, Artur Frenszek-Iwicki wrote:
Once you open the app screen details, there is a drop-down for this, integrated into the top bar, next to the app name.
Too complicated for the average user. It should be visible when you click the "Install" button.
Too complicated for the average user.
That's debatable. Does the *average user* even care? We're on the development mailing list, after all, so there's a lot of bias towards the power user side.
It should be visible when you click the "Install" button.
I agree that the current placement makes the source dropdown not very visible and easy to miss. I was thinking if having some kind of combo-button (i.e. button + dropdown) would be a better option - something like: + ------------------+---+ | Install | | | (From Fedora RPM) | v | +-------------------+---+ This would make the selected source prominent and allow to easily switch to a different one.
Either way, this is all a UX discussion, and with GNOME's take-it-or-leave-it approach, I fear we'd have to patch gnome-software to achieve something like the above, which would probably create a lot of maintenance burden.
A.FI.
On 30/06/2022 16:18, Artur Frenszek-Iwicki wrote:
That's debatable. Does the*average user* even care? We're on the development mailing list, after all, so there's a lot of bias towards the power user side.
True. Most users don't care, so they will get Flatpaks instead of RPMs.
Too complicated for the average user. It should be visible when you
click the "Install" button.
I agree. There is currently a proposal to display the sources dropdown below the "install". It looks way better and more discoverable.
Too complicated for the average user. It should be visible when you
click the "Install" button.
I agree. There is currently a proposal to display the sources dropdown below the "install". It looks way better and more discoverable.
Artur Frenszek-Iwicki wrote:
That being said, what about allowing users to set this preference by themselves?
That would make a lot of sense indeed (though the default would still need to be agreed on). But unfortunately, asking for any kind of user preference to be added to a GNOME application is usually a lost cause. GNOME has a strict "take it or leave it" policy.
Kevin Kofler
On Thu, Jun 30 2022 at 02:20:58 PM +0200, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
That would make a lot of sense indeed (though the default would still need to be agreed on). But unfortunately, asking for any kind of user preference to be added to a GNOME application is usually a lost cause. GNOME has a strict "take it or leave it" policy.
I actually agree that it makes sense to have a preference for this. We discussed it in the past but gave up because it required effort. The current Software Sources page is not designed to allow you to reorder sources in arbitrary ways. It would be easy to expose a switch for the current "prefer flatpak vs. prefer RPM setting," but that might not be powerful enough for what users actually want, e.g. it doesn't allow you to prefer Fedora flatpak > Fedora RPM > Flathub, or Flathub > Fedora RPM > Fedora Flatpak. I think this is probably a "help welcome" area.
Of course, users have the final choice when installing.
Michael
On Thu, Jun 30, 2022 at 10:11:43AM -0500, Michael Catanzaro wrote:
We discussed it in the past but gave up because it required effort. The current Software Sources page is not designed to allow you to reorder sources in arbitrary ways. It would be easy to expose a switch for the current "prefer flatpak vs. prefer RPM setting," but that might not be powerful enough for what users actually want, e.g. it doesn't allow you to prefer Fedora flatpak > Fedora RPM > Flathub, or Flathub > Fedora RPM > Fedora Flatpak. I think this is probably a "help welcome" area.
The thing I'd like to see, but which I don't even have any good ideas for myself: *after* installation, making it easy to know where running applications come from and where to get help or report problems -- ideally separately for the app itself and for packaging/distribution -- all without being obnoxiously in your face during normal operation.
Please remember that Flathub remains disabled by default even if this change proposal is fully implemented. It's gated behind the "enable third-party software?" switch. So if you only want free software from Fedora, you'll just leave that switch off and never see anything from Flathub. (In fact, enabling it by default would actually be prohibited by previous FESCo and Fedora Council decisions.) But users who do choose enable third-party software really want to see Flathub unfiltered, not our confusing and annoying limited view of Flathub.
On Thu, Jun 30 2022 at 11:18:04 AM +0200, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Users of RPM-based variants will expect the default package manager to install RPMs, not Flatpaks, or they would have chosen a Flatpak-based variant.
Any such expectations are misplaced. The people working on Silverblue do not feel that it is ready to become Fedora Workstation yet, but Flatpaks are certainly ready and there's no need to wait. Various discussions about using more flatpaks:
https://pagure.io/fedora-workstation/issue/151 (resolved long ago) https://pagure.io/fedora-workstation/issue/269 (next up) https://pagure.io/fedora-workstation/issue/300 (this change proposal)
I take a pretty dim view towards arguments about "Flathub is untrusted" and "Flathub packaging is poor" since proponents of these arguments conveniently ignore the fact that traditional RPMs are totally unsandboxed. One memory safety bug and your PDF reader, video player, or other native app has full control of your user account and can do whatever it wants with all your files. And Linux apps have *lots* of memory safety bugs. With the exception of web browsers (all of which have strong sandboxes), few other apps are even trying to sandbox themselves. I'm not too interested in rehashing the same old arguments about this because it has all been well-known and said many, many, many times before. (Yes, system libraries are generally safer than bundled libraries. No, this is not anywhere near as important as having a strong sandbox. Yes, many apps on Flathub sabotage the sandboxing to the point where it is meaningless, and yes that should be discouraged harder somehow.)
Opponents of Flatpak have had seven years since Flatpak launched to figure out an alternative model to make apps safe using firejail or bwrap or whatever, but nobody ever seriously did, and at this point the endgame has arrived with a *commanding* lead in favor of Flatpak. So it's time to move on.
Having third-party Flatpaks take precedence over Fedora RPMs that nobody has bothered to Flatpak is a very intentional choice to improve user safety (again, only if users opt-in to third-party software). But you can ensure the Fedora version of an app takes precedence by creating a Fedora Flatpak for it. And users ultimately have full control over which source they use to install.
Regardless, Fedora will still be RPM-based no matter what. ;) Even if our future is OS images composed of RPMs plus Flatpaks composed by RPMs, it's still based on RPMs. (Of course stuff from Flathub is not based on RPMs, but we wouldn't expect third-party stuff to be.)
Michael
On 30/06/2022 16:23, Michael Catanzaro wrote:
I take a pretty dim view towards arguments about "Flathub is untrusted" and "Flathub packaging is poor" since proponents of these arguments conveniently ignore the fact that traditional RPMs are totally unsandboxed.
I would prefer a non-sandboxed app instead of a third-party DEB repack.
On Thu, Jun 30, 2022, at 10:23 AM, Michael Catanzaro wrote:
Regardless, Fedora will still be RPM-based no matter what. ;) Even if our future is OS images composed of RPMs plus Flatpaks composed by RPMs, it's still based on RPMs.
I don't think so. I think RPM is a tool, a technique that can be used where it makes sense. It is not and should not be the center of the universe. Today in Fedora CoreOS we ship a bit of content that comes directly from the https://github.com/coreos/fedora-coreos-config git repository without having been pointlessly put into an RPM first.
Building an intermediate RPM for content that is *only* intended to be run as a container is just awkward and strange.
On 7/1/22 8:02 AM, Colin Walters wrote:
On Thu, Jun 30, 2022, at 10:23 AM, Michael Catanzaro wrote:
Regardless, Fedora will still be RPM-based no matter what. ;) Even if our future is OS images composed of RPMs plus Flatpaks composed by RPMs, it's still based on RPMs.
I don't think so. I think RPM is a tool, a technique that can be used where it makes sense. It is not and should not be the center of the universe. Today in Fedora CoreOS we ship a bit of content that comes directly from the https://github.com/coreos/fedora-coreos-config git repository without gavina been pointlessly put into an RPM first.
It removes a step so it makes it easier, but at the same time remove the existence of a copy of the source code (SRPM) in parallel with the binaries.
There is a reason all Fedora RPMs sources are stored on Fedora infrastructure instead of automatic downloads from source repositories. Imagine an entire Fedora built that way and think about the reproducibility of that build. Maybe another process could replace it, but going directly to source repositories is a step backwards.
Building an intermediate RPM for content that is *only* intended to be run as a container is just awkward and strange. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Jul 01, 2022 at 08:30:33AM -0400, Robert Marcano via devel wrote:
It removes a step so it makes it easier, but at the same time remove the existence of a copy of the source code (SRPM) in parallel with the binaries.
We absolutely need that, but source RPMs are not the only (or best!) way to do that.
There is a reason all Fedora RPMs sources are stored on Fedora infrastructure instead of automatic downloads from source repositories. Imagine an entire Fedora built that way and think about the reproducibility of that build. Maybe another process could replace it, but going directly to source repositories is a step backwards.
If we had all of the source exploded into source repositories under our control, and built from that, we probably could get _more_ reproducibility.
On Fri, Jul 01, 2022 at 08:02:35AM -0400, Colin Walters wrote:
I don't think so. I think RPM is a tool, a technique that can be used where it makes sense. It is not and should not be the center of the universe. Today in Fedora CoreOS we ship a bit of content that comes directly from the https://github.com/coreos/fedora-coreos-config git repository without having been pointlessly put into an RPM first.
Building an intermediate RPM for content that is *only* intended to be run as a container is just awkward and strange.
I agree. RPM makes sense at for the things it solves well, but we should figure out how we can provide the same (or more) value in other ways too. I know this is a blast from the past, but this was a central idea from my talk at Flock in 2013 (https://mattdm.org/fedora/2013next/) and I still believe we need to get there.
I'd love to see a way to generate Flatpaks directly from our build system without an intermediate step. Part of the justification for the current system is an early estimate that 95% of desktop apps already packaged could have flatpak versions without any additional work... that turned out to be not so in practice. It was a good experiment, but we shouldn't feel stuck to it. (Also, it was expecting a lot more improvements in modularity infrastructure which never got resourced for reasons not worth rehashing.)
Same goes for some container content, too. Thinking about java stuff there in particular, as well as various web-apps we package.
On 01/07/2022 20:32, Matthew Miller wrote:
I'd love to see a way to generate Flatpaks directly from our build system without an intermediate step.
+1. Flatpaks should be built natively on our trusted infra from standard Flatpak manifests.
Vitaly Zaitsev via devel wrote:
On 01/07/2022 20:32, Matthew Miller wrote:
I'd love to see a way to generate Flatpaks directly from our build system without an intermediate step.
+1. Flatpaks should be built natively on our trusted infra from standard Flatpak manifests.
While we agree on almost all points, in this case I disagree in so much as I think Fedora should not be in a business of building Flatpaks at all, neither from RPMs, nor directly. The Flatpak technology has just too many drawbacks compared to good old RPMs. And the Fedora Flatpaks project is essentially unmaintained, or the required fedmod tool would not have been retired months ago (and not unretired since).
Kevin Kofler
On 6/30/22 10:23, Michael Catanzaro wrote:
I take a pretty dim view towards arguments about "Flathub is untrusted" and "Flathub packaging is poor" since proponents of these arguments conveniently ignore the fact that traditional RPMs are totally unsandboxed. [...]
Opponents of Flatpak have had seven years since Flatpak launched to figure out an alternative model to make apps safe using firejail or bwrap or whatever, but nobody ever seriously did, and at this point the endgame has arrived with a *commanding* lead in favor of Flatpak. So it's time to move on.
There are two separate issues: sandboxing and library duplication/lifecycle management. I agree that sandboxing is desirable, but I don't think we should give up on the shared libraries, because of their savings of memory and storage, and because of their better security profile.
I see how RPM-driven flatpaks can actually mitigate the security issue--presumably any vulnerability fixes/updates to system libraries also end up in the rebuilt flatpaks, so they would not rot in place. Still, the library/runtime duplication bothers me and I hope that there will be some technical solution to it.
On Wed, Jun 29, 2022 at 8:42 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
Flathub should only be preferred when there is no Fedora Flatpak
available.
I don't see it in the proposal.
I see: "GNOME Software will prefer Fedora flatpaks over Flathub flatpaks"
What is *not* in the proposal and should be added is a clarification whether Fedora RPMs or Flathub flatpaks take precedence, when both exist (and a Fedora flatpak doesn't). My preference would be: Fedora flatpak > Fedora RPM > Flathub or Fedora RPM > Fedora flatpak > Flathub
If this is the case, I believe this Change is a great benefit to Fedora. I'd be worried if we prioritized third-party software over our own builds. Yes, the security is better with flatpak over rpm, but there are also other aspects. Like having things under our own control, or having a pretty good pre-release testing processes (updates-testing, bodhi, karma) compared to flathub.
On Thu, Jun 30, 2022 at 4:50 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
I would prefer a non-sandboxed app instead of a third-party DEB repack.
And nobody is taking that option away from you ;-) You've made your preference known. Repeating it numerous times doesn't contribute to a pleasant discussion.
On Fri, Jul 1 2022 at 01:37:01 PM +0200, Kamil Paral kparal@redhat.com wrote:
What is *not* in the proposal and should be added is a clarification whether Fedora RPMs or Flathub flatpaks take precedence, when both exist (and a Fedora flatpak doesn't). My preference would be:
Flatpaks already take precedence over RPMs, and there are no plans to change this for the reasons I mentioned in my previous mail regarding sandboxing, which is more important than other considerations.
As mentioned previously, GNOME Software can be configured to prefer RPMs over Flatpaks, but it cannot currently be configured to allow arbitrary orderings: that would require additional design and development work. Users can always have the final say if they wish to explicitly select the installation source when installing the app.
Michael
On Wednesday, 29 June 2022 at 20:25, Michael Catanzaro wrote:
On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
- GNOME Software need to be patched to prefer RPMs over Flatpaks for
non-ostree Fedora variants, because it will replace Fedora packages with Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM" for Silverblue/Kinoite will be better.
GNOME Software already has a hidden setting for this:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/0709681441daf6b182a062d...
It defaults to Flatpaks because they are sandboxed and are much safer than unsandboxed applications.
... *when* they are sandboxed ... Unfortunately, in many cases, they aren't.
However, I believe Flatpaks built from Fedora RPMs should take precedence over Flatpaks built from Flathub. Flathub should only be preferred when there is no Fedora Flatpak available.
+1
Regards, Dominik
On Thu, 30 Jun 2022 at 10:41, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
... *when* they are sandboxed ... Unfortunately, in many cases, they aren't.
I don't think that "some apps have lots of holes punched in the sandbox, but can be locked down easily using a GUI tool, where the majority are indeed locked down" can reasonably be compared to the distro packages that are never run in sandboxes and cannot be locked down in the same way. By that logic we should remove all distro applications because they can't be locked down or sandboxed by the user in any meaningful way.
As the person who's been driving AppStream to make desktop applications easier to install on Linux for the last decade (!) I can tell you that flatpaks are in almost all cases what users should be using. By any metric (e.g. live updates, portals, sandboxing, per-user/per-system) they blow apps-as-packages out of the water. Use packaged versions of your apps if you want to, but please don't veto a feature that 99.99% of Fedora users categorically should be using.
Richard
Richard Hughes wrote:
As the person who's been driving AppStream to make desktop applications easier to install on Linux for the last decade (!) I can tell you that flatpaks are in almost all cases what users should be using. By any metric (e.g. live updates, portals, sandboxing, per-user/per-system) they blow apps-as-packages out of the water. Use packaged versions of your apps if you want to, but please don't veto a feature that 99.99% of Fedora users categorically should be using.
You are conveniently ignoring the drawbacks of the approach, see, e.g.: http://flatkill.org/ and that is by no means a complete list.
Kevin Kofler
On 30/06/2022 14:22, Kevin Kofler via devel wrote:
You are conveniently ignoring the drawbacks of the approach, see, e.g.: http://flatkill.org/ and that is by no means a complete list.
See also: https://ludocode.com/blog/flatpak-is-not-the-future
The two articles mentioned above all full of errors and misconceptions about how Flatpak and Flathub works.
See https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-...
Timothée Ravier wrote:
The two articles mentioned above all full of errors and misconceptions about how Flatpak and Flathub works.
See https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-...
Oh, I know that "response". That response fails to convincingly address any of the criticism in the "Flatpak is not the Future" article.
Let me just go through the first section, "Size":
Section introduction: * The response first tries to explain away the problem, trying to tell us why it is so bad to use host libraries (contrary to the best practices Fedora has been trying to promote all this time). * Then it explains that we do not in fact have a 900 MB calculator, but "only" a 550 MB calculator, as if that were any more acceptable.
Sharing Runtimes: The response seriously tries to sell us "113 MB out of 498 MB were deduplicated" (less than ¼) and "388 MB out of 715 MB were deduplicated" (about half) as a success of deduplication. (That is still a 75% resp. 50% space waste compared to having just one runtime.)
Storage Usage: "Only 13.07 GB are used with deduplication", LOL, enough said! Though, if you insist on percentages, "13.07 GB are used with deduplication" vs. "36.22 GB without" means that 64% are saved and 36% are still used if you have an incredible "57 runtimes". (Fewer runtimes also mean less opportunity to deduplicate.) Still, 57 times 36% is still a factor of more than 20, i.e., the proliferation of runtimes means you need 20 times the space for runtimes that a single shared runtime (as in the RPM world) would need.
"Disk space is cheap!": * The criticism was that this no longer holds, which seems obvious looking at current prices. Yet, the response still tries to explain that away by claiming that "flash storage have higher physical density than hard drives because of built-in compression and deduplication". But no amount of compression and deduplication can increase the worst-case size of the disk that can be relied on, because it only works on data that is compressible or duplicate. * The response then proceeds to showing gains on Flatpak data from partition-level deduplication and compression (which is not actually a feature of flash storage at all, but of the in-kernel file system). That there is anything to be gained at all from partition-level deduplication just shows that Flatpak's own deduplication is nowhere near as effective as advertised. And partition-level compression is 1. slow and 2. can also be done just as effectively on software installed from RPMs (so it is not fair to compare compressed Flatpak installations with uncompressed RPM installations for size).
Memory Usage, Startup Time: The response starts with "This is assuming the user has the same applications installed on the system and as a Flatpak and wants to load both.", which is a false assertion. In order to share libraries in memory, the applications need not be the same, they just need to use the same libraries, e.g., Qt, GTK, etc., and they typically do. So the whole two response paragraphs that follow are invalid (due to being deduced from this false premise).
I can take apart the rest when I have more time, but you should get the idea.
Kevin Kofler
I don't believe the technical details are as significant as the systemtic change to the boundaries of trusted software maintainers.
Consider this comment, which appears to be the core justification:
Michael Catanzaro wrote:
Flatpaks already take precedence over RPMs, and there are no plans to change this for the reasons I mentioned in my previous mail regarding sandboxing, which is more important than other considerations.
A sandboxed trojan application is still capable of damaging the user's security, even if it can't damage the system's security.
To illustrate the difference, a subverted browser can share all credit card details seen (user's security compromised), but removing that software removes the subversion (system security not compromised)
A preference order of
Fedora Flatpak > GNOME Flatpak > Fedora RPM
makes user's security of graphical applications reliant upon a wider set of trusted software maintainers than
Fedora Flatpak > Fedora RPM > GNOME Flatpak
Essentially, for graphical applications the change makes Fedora trust and security processes approach the minimum of of Fedora trust and security processes and GNOME trust and security processes. That's change to the security stance of the distribution which requires explicit discussion prior to accepting the change.
-glen
Michael Catanzaro wrote:
However, I believe Flatpaks built from Fedora RPMs should take precedence over Flatpaks built from Flathub. Flathub should only be preferred when there is no Fedora Flatpak available.
That is not a solution, because Fedora Flatpaks are effectively an abandoned feature, as evidenced by the next thread, which points out that a required tool was removed from the repository more than 6 months ago.
We need Fedora RPMs to take precedence over Flatpaks built from Flathub, not just Flatpaks built from Fedora RPMs.
Kevin Kofler
On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth siddharthvipul1@gmail.com wrote:
== Detailed Description ==
Fedora includes a flatpak repo definition for Flathub in the fedora-flathub-remote package. So far, this remote was filtered by an allowlist that only made a limited subset of software from Flathub available. We've been told that it is ok for us to remove the filtering and make all of Flathub available.
Given that flathub provides similar / overlapping content compared to RPMFusion (or often, even more "legally problematic" than what's available from RPMFusion, i.e. prebuilt blobs), doesn't this same reasoning also apply there? I.e. can Fedora enable the full rpmfusion repositories by default, as well, instead of only the separate ("filtered") repositories for the proprietary NVidia drivers and the Steam client?
Fabio
On 30/06/2022 11:35, Fabio Valentini wrote:
I.e. can Fedora enable the full rpmfusion repositories by default, as well, instead of only the separate ("filtered") repositories for the proprietary NVidia drivers and the Steam client?
They don't want to answer why they can't preload RPM Fusion: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
LWN news article: https://lwn.net/Articles/897793/
On Thu, Jun 30 2022 at 12:16:09 PM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
They don't want to answer why they can't preload RPM Fusion: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
You actually linked straight to the answer. Matthew's response there is not some passing speculation; that's the real answer based on discussion with Fedora Legal.
Michael
On 30/06/2022 16:44, Michael Catanzaro wrote:
You actually linked straight to the answer. Matthew's response there is not some passing speculation; that's the real answer based on discussion with Fedora Legal.
This is not a real answer. These are double standards.
RPM Fusion is a third-party repository too which provides software for various Linux distributions: Fedora Linux, Red Hat Enterprise Linux, Rocky Linux and Alma Linux.
On Thu, Jun 30 2022 at 05:02:35 PM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
This is not a real answer. These are double standards.
It's not a double standard: Matthew explained precisely why RPM Fusion is different and riskier than Flathub. I'm sorry it's not the answer that you wanted to hear, but rest assured it is the actual answer.
I do not expect Fedora Legal will likely come onto a public mailing list to debate liability with you. Hopefully it should be obvious why that's not a good idea. There's nothing more I can do except link you back to Matthew's post. Sorry.
Michael
On 30/06/2022 17:23, Michael Catanzaro wrote:
I do not expect Fedora Legal will likely come onto a public mailing list to debate liability with you. Hopefully it should be obvious why that's not a good idea. There's nothing more I can do except link you back to Matthew's post. Sorry.
These are double standards. I don't why they hate RPM Fusion.
Fedora is a public, community-driven distribution, so they must post an official response to our request.
On Thu, Jun 30, 2022 at 3:33 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 30/06/2022 17:23, Michael Catanzaro wrote:
I do not expect Fedora Legal will likely come onto a public mailing list to debate liability with you. Hopefully it should be obvious why that's not a good idea. There's nothing more I can do except link you back to Matthew's post. Sorry.
These are double standards. I don't why they hate RPM Fusion.
Fedora is a public, community-driven distribution, so they must post an official response to our request.
No, they do not, really. Community driven does not (never has) meant that the community has the final decision on everything.
If you do not understand this, talk to *your* lawyer (only your lawyer is responsible to you) and have them explain the details and distinctions and reasonings to you.
Whether the RH lawyers recommendations in this case are good or not, or whether anyone agrees or not, is, ultimately, not really relevant.
Gary
On 30/06/2022 17:47, Gary Buhrmaster wrote:
If you do not understand this, talk to*your* lawyer (only your lawyer is responsible to you) and have them explain the details and distinctions and reasonings to you.
Each court publishes the reasoning part of the decision.
On 6/30/22 11:08, Vitaly Zaitsev via devel wrote:
On 30/06/2022 17:47, Gary Buhrmaster wrote:
If you do not understand this, talk to*your* lawyer (only your lawyer is responsible to you) and have them explain the details and distinctions and reasonings to you.
Each court publishes the reasoning part of the decision.
This is not a court. It is a group of attorneys providing advice to their client (which happens to be their employer).
On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth <siddharthvipul1(a)gmail.com> wrote:
Given that flathub provides similar / overlapping content compared to RPMFusion (or often, even more "legally problematic" than what's available from RPMFusion, i.e. prebuilt blobs), doesn't this same reasoning also apply there? I.e. can Fedora enable the full rpmfusion repositories by default, as well, instead of only the separate ("filtered") repositories for the proprietary NVidia drivers and the Steam client?
Note that the proposal is not about enabling Flathub, only about its filtering. As far as I understand it remains off by default.
But RPMfusion was my first thought , too. We don't even ship the repo definitions, do we, and enabling "third party software" in Gnome software center does not enable RPMfusion. Why not?
My second thought was about packaging. Why should I inverst my free time into rpm packaging, especially unbundling, caring about dependent packages etc. - i.e. evreything which makes a distro a distro - when the preferred "packaging" switches to flatpaks?
"Additionally, the filtered Flathub has not been popular with users. [...] Dropping the filter will resolve this criticism."
While we do our packaging work *for* the users, that argument really doesn't convice me. Give them "curl | sudo sh" because it's so simple and provides more applications? Let npm and cargo and pip install right into /usr? Much easier and so many apps! What could go wrong?
On 30/06/2022 12:40, Michael J Gruber wrote:
Note that the proposal is not about enabling Flathub, only about its filtering. As far as I understand it remains off by default.
Flathub is already preloaded and enabled by default, but filtered. Now they want to remove this filter.
This will make the Fedora packagers work useless, because GNOME Software will always prefer Flathub packages.
On Thu, Jun 30 2022 at 01:54:16 PM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
Flathub is already preloaded and enabled by default,
Actually it's NOT enabled by default, and we do not propose to change that. To get Flathub, users must either:
* Press the Enable Third-Party Repositories button on the Third-Party Repositories page in gnome-initial-setup, or * Flip one or more switches at the bottom of the Software Repositories dialog in GNOME Software
The goal is to make it easy for users to find third-party software if they choose to enable it, but by default stay limited to only open source software provided by Fedora.
Michael
The Flathub remote is available to users who opt-in to enabling third-party software repositories in either GNOME Initial Setup or GNOME Software.
A lot of flatpaks in Flathub have debatable quality, and are closed source. If we could wait until flathub separates open-source and proprietary repos, the open-source one could be unfiltered, and the proprietary one could have a blacklist for very bad packages. I think it would be better if there could be some sort of warning in GNOME software, so maintainers could mark certain packages as unsafe or low-quality.
and the proprietary one could have a blacklist for very bad packages.
The ability remains to filter if there is a package that is considered bad or malicous. The default is just changed to an allow list. Secondly if there is a malicious package, it will probably be faster to contact flathub and have them take action that make a downstream update to block it.
devel@lists.stg.fedoraproject.org
-
Artur Frenszek-Iwicki -
Colin Walters -
Daniel P. Berrangé -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Gary Buhrmaster -
Glen Turner -
Jarryd Lisher -
Joaquim Nascimento -
Kamil Paral -
Kevin Kofler -
Kevin P. Fleming -
Marc Pervaz Boocha -
Matthew Miller -
Michael Catanzaro -
Michael J Gruber -
Naheem Zaffar -
Neal Gompa -
Przemek Klosowski -
Richard Hughes -
Robert Marcano -
Sharpened Blade -
Timothée Ravier -
Vipul Siddharth -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek