I have learned that we are now ok to drop filtering for flathub and just make the unfiltered remote available as-is.
Can we still make stuff from Fedora preferred over Flathub then?
Woo hoo!
To implement this for Fedora 37:
GNOME Software has a "packaging-format-preference" key to determine whether RPMs or Flatpaks are preferred. Looking at the source doesn't make it obviously clear how prioritization within Flatpaks ends up happening.
Right now, we have no ability to do something like Fedora Flatpaks > Fedora RPMs > Flathub Flatpaks - if wanted that, that would have to be implemented in GNOME Software.
Er, so everything from Flathub is fine now, no restrictions? Seriously great news. In this case, I'd say priority one is to stop shipping Fedora's Firefox and Totem altogether, and default to getting them from Flathub instead.
We had just yesterday started discussions on how to start stripping problematic multimedia stuff out of freedesktop-sdk in order to be friendlier to our filtered flathub remote. Sounds like that is no longer needed, and we can simplify things a lot.
To implement this for Fedora 37: We need figure out prioritization between Fedora RPMs and Flathub
Proposal: change nothing, flatpaks continue to take precedence over RPMs.
We need to figure out priotization between Fedora Flatpaks and Flathub Flatpaks
Proposal: Fedora flatpaks should take precedence, and we retire Fedora flatpaks that would benefit from unrestricted multimedia codecs available on flathub (specifically Firefox and Totem)
We need to figure out prioritization between Flathub Flatpaks and 3rd party RPM repositories - especially for IDEs
I would drop the third-party RPM repositories. If the flatpak versions have bugs, those bugs should be fixed, and not dictate our packaging format strategy.
We need to figure out what happens on upgrade from older versions - if we want "Fedora Flathub Selection" to turn into "Flathub", that will need fedora-third-party support.
Surely this is what we want.
To implement this for Fedora 37: We need figure out prioritization between Fedora RPMs and Flathub Proposal: change nothing, flatpaks continue to take precedence over RPMs.
Meh.
We need to figure out priotization between Fedora Flatpaks and Flathub Flatpaks Proposal: Fedora flatpaks should take precedence, and we retire Fedora flatpaks that would benefit from unrestricted multimedia codecs available on flathub (specifically Firefox and Totem)
Yes to Fedora precedence, no to retiring Fedora flatpaks.
We need to figure out prioritization between Flathub Flatpaks and 3rd party RPM repositories - especially for IDEs I would drop the third-party RPM repositories. If the flatpak versions have bugs, those bugs should be fixed, and not dictate our packaging format strategy.
I don't want this. I prefer RPMs over Flatpaks and I'd prefer to maintain the choice.
We need to figure out what happens on upgrade from older versions - if we want "Fedora Flathub Selection" to turn into "Flathub", that will need fedora-third-party support. Surely this is what we want.
Probably?
Er, so everything from Flathub is fine now, no restrictions? Seriously great news. In this case, I'd say priority one is to stop shipping Fedora's Firefox and Totem altogether, and default to getting them from Flathub instead. We had just yesterday started discussions on how to start stripping problematic multimedia stuff out of freedesktop-sdk in order to be friendlier to our filtered flathub remote. Sounds like that is no longer needed, and we can simplify things a lot.
Well, one, I would personally oppose doing it for Workstation/KDE. Two, using Flathub's Firefox means none of our bookmarks, start pages, privacy settings, enhancements, etc. are available. Three, the Flatpaks have a measurably worse experience than the RPMs.
Some addons will not work as intended with firefox flatpak https://bugzilla.mozilla.org/show_bug.cgi?id=1621763 and many other problems https://bugzilla.mozilla.org/show_bug.cgi?id=flatpak
It's not so simple. For IDEs, those "bugs" amount to fundamental redesigns just for flatpak. Unless flatpak grows a classic mode that would allow IDEs to work like they already do on other platforms, the flatpak version of IDEs like PyCharm will remain fundamentally crippled.
classic
I second that. However, I don't think we should be promoting Firefox Flatpak from Fedora Flatpaks because it's behind most of the time. The one from Flathub gets the new update within hours whereas the one from the Fedora repos can take weeks. Since Fedora strives on security, we shouldn't be delaying browser updates.
Can we still make stuff from Fedora preferred over Flathub then? I second that. However, I don't think we should be promoting Firefox Flatpak from Fedora Flatpaks because it's behind most of the time. The one from Flathub gets the new update within hours whereas the one from the Fedora repos can take weeks. Since Fedora strives on security, we shouldn't be delaying browser updates.
Mozilla is also behind on integrating fixes we develop, so it goes both ways. I'm fine with prioritizing our work.
Also, Firefox is not "weeks" behind. For the last several Firefox updates, including the update to Firefox 99, we were only behind by 2 days.
https://bodhi.fedoraproject.org/updates/?packages=firefox
Does upstream Firefox still disable ASLR in order to allow launching the binary by double clicking on it in nautilus? That's one of the dumber decisions in the history of Linux, and doesn't speak well of the security of upstream builds. I have much greater trust in Fedora hardening flags.
That said, it's irrelevant if upstream builds can play multimedia and our builds can't. That single consideration is more important than all other factors.
Does upstream Firefox still disable ASLR in order to allow launching the binary by double clicking on it in nautilus? That's one of the dumber decisions in the history of Linux, and doesn't speak well of the security of upstream builds. I have much greater trust in Fedora hardening flags. That said, it's irrelevant if upstream builds can play multimedia and our builds can't. That single consideration is more important than all other factors.
Our builds can play pretty much all web multimedia, if our ffmpeg-free and openh264 packages are installed on the system. We just don't currently preload ffmpeg-free on the system and we don't have the launch script request and install the mozilla-openh264 package via PackageKit when Firefox is started if the package hasn't already been installed.
ffmpeg-free
mozilla-openh264
I agree with that. I'm very tired of media not playing just because I opened the wrong firefox.
Well, here's an attempt to resolve the main multimedia issue by installing openh264: https://src.fedoraproject.org/rpms/firefox/pull-request/41
Strongly -1, because Flatpaks have higher priority over RPMs.
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:
Also if we're allowed to preinstall unfiltered Flathub, than we can do the same for the RPM Fusion repository. Users will have fully featured ffmpeg with all codecs support.
We are still not able to do this. Sorry.
Strongly -1, because Flatpaks have higher priority over RPMs. 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.yaml#L62-L65 https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L97-L101 https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L143-L145
Depends what you mean by trusted. I certainly trust Flathub's applications more than Fedora's. It's much easier to contact developers or contribute to manifests. Heck, there isn't even a Matrix room for Fedora Flatpaks where you can ask questions to developers who maintain Fedora Flatpaks.
I trust apps that are provided by first parties like OBS Studio and Firefox. Furthermore, I've had a much better experience with apps from Flathub than their Fedora Flatpaks counterpart. It's anything but low-quality.
FTR, Firefox from Fedora Flatpaks gives read-only permissions to $HOME^. Firefox from Flathub only has read-write access to Downloads directory^. Of course, I can use Flatseal but I shouldn't need to do that especially when the application in question uses XDG portals. And Firefox from Flathub always has the latest updates within hours whereas Firefox from Fedora are often a couple of days late. This gives me even more reasons to trust Flathub's more than Firefox Flatpaks's.
I find repackaging distributing via Flatpak a lot more trustworthy than installing on the system thanks to the sandboxing and Flatseal.
They're both great remotes, but I trust Flathub more.
Can we still make stuff from Fedora preferred over Flathub then? I second that. However, I don't think we should be promoting Firefox Flatpak from Fedora Flatpaks because it's behind most of the time. The one from Flathub gets the new update within hours whereas the one from the Fedora repos can take weeks. Since Fedora strives on security, we shouldn't be delaying browser updates. Mozilla is also behind on integrating fixes we develop, so it goes both ways. I'm fine with prioritizing our work. Also, Firefox is not "weeks" behind. For the last several Firefox updates, including the update to Firefox 99, we were only behind by 2 days. https://bodhi.fedoraproject.org/updates/?packages=firefox
Hence "can". I had no intention to say that it is always a week late, sorry for that. Anyway, I don't trust when packages can be a week behind and/or sometimes several days behind. Browsers are not your average application; they are critical and huge targets for bad actors. IMO it's not something we should be delaying, even for a couple of days.
Strongly -1, because Flatpaks have higher priority over RPMs. 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.yaml#L62-L65 https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L97-L101 https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L143-L145 Depends what you mean by trusted. I certainly trust Flathub's applications more than Fedora's. It's much easier to contact developers or contribute to manifests. Heck, there isn't even a Matrix room for Fedora Flatpaks where you can ask questions to developers who maintain Fedora Flatpaks. I trust apps that are provided by first parties like OBS Studio and Firefox. Furthermore, I've had a much better experience with apps from Flathub than their Fedora Flatpaks counterpart. It's anything but low-quality. FTR, Firefox from Fedora Flatpaks gives read-only permissions to $HOME^. Firefox from Flathub only has read-write access to Downloads directory^. Of course, I can use Flatseal but I shouldn't need to do that especially when the application in question uses XDG portals. And Firefox from Flathub always has the latest updates within hours whereas Firefox from Fedora are often a couple of days late. This gives me even more reasons to trust Flathub's more than Firefox Flatpaks's.
The Flathub default is painful for a lot of application experiences. For example, working with rich chat and trying to upload images or video clips is impossible by default. Frankly, it's incredibly asinine that someone thought that was reasonable.
The need for Flatseal as a separate app is a huge flaw. That should be part of software center itself.
I don't. Flathub is a scary source to me. And I fundamentally distrust systems that promote opaque software delivery methodologies.
Can we still make stuff from Fedora preferred over Flathub then? I second that. However, I don't think we should be promoting Firefox Flatpak from Fedora Flatpaks because it's behind most of the time. The one from Flathub gets the new update within hours whereas the one from the Fedora repos can take weeks. Since Fedora strives on security, we shouldn't be delaying browser updates. Mozilla is also behind on integrating fixes we develop, so it goes both ways. I'm fine with prioritizing our work. Also, Firefox is not "weeks" behind. For the last several Firefox updates, including the update to Firefox 99, we were only behind by 2 days. https://bodhi.fedoraproject.org/updates/?packages=firefox Hence "can". I had no intention to say that it is always a week late, sorry for that. Anyway, I don't trust when packages can be a week behind and/or sometimes several days behind. Browsers are not your average application; they are critical and huge targets for bad actors. IMO it's not something we should be delaying, even for a couple of days.
No. Just, no. Even in Windows/Mac land, updates do not reach people directly from developers within the first day. On my Mac, Chrome does not even prompt for updates until about a week after it's been made available. On Windows, it is sometimes even longer for Firefox, Chrome, and other "critical" apps.
We do much better than them already.
Er, what? Apps have a responsibility to not be completely stupid. Using the file chooser portal is not rocket science. xdg-desktop-portal has been around for long enough that we can reasonably expect applications to know how to do this.
Maybe the app you're having trouble with should just not be packaged as a flatpak at all, if it's not ready for it.
This is a power user tool for software developers. End users should never need it. If you feel the need to use flatseal, that's a serious bug.
I haven't had issues (except for Discord) since I can upload host files in a sandboxed environment thanks to the XDG FileChooser portal. Electron and Chromium support it, Firefox does too, GTK and Qt apps as well, etc.
I don't see how these are "opaque software delivery methodologies". Everything is easily available publicly and uses OSTree to publish applications. With Fedora Flatpaks, you have to dig through undocumented/badly documented sources for a long time just to get some understanding. Those that do have some relevant information are hidden away from search engines because of terrible SEO. It also uses OCI containers in a nonstandard approach, and in turn is not well documented either. If anything, Fedora Flatpaks is far worse than Flathub in the realm of opaqueness.
And believe me, I have first hand experience with researching Fedora Flatpaks. I wrote articles to better explain the existence of Fedora Flatpaks, because most users don't see the point of Fedora Flatpaks altogether. I literally spent weeks to research because relevant sources are extremely difficult to find. With Flathub, I can easily find resources. It's not even clear whether "Fedora Flatpaks" is the official name for Fedora's remote, and who knows if it actually is the official name.
I learned Flathub and Flatpak from scratch by reading documentation and watching a couple of videos. Even with my knowledge from learning Flatpak, I had a really hard time understanding Fedora Flatpaks.
No. Just, no. Even in Windows/Mac land, updates do not reach people directly from developers within the first day. On my Mac, Chrome does not even prompt for updates until about a week after it's been made available. On Windows, it is sometimes even longer for Firefox, Chrome, and other "critical" apps. We do much better than them already.
I do agree that what Fedora does is much better. However, doing better than the alternatives doesn't necessarily mean it's good. Firefox from Flathub is still leagues ahead because users get updates the same day.
Then most Flatpaks should be gone from Flathub.
I don't see how these are "opaque software delivery methodologies". Everything is easily available publicly and uses OSTree to publish applications.
Umm, then why does Flathub allow people pushing unverifiable blobs right into its OSTree remote? OBS Studio, Firefox, etc. are all done outside. And a number of "transparent" Flatpaks are just repacked opaque packages with no trustable source and no support from the developer or the packager, which is even worse.
You and I have very different definitions here. For all the convoluted stuff with Fedora Flatpaks, at least it's possible to see how they're built and change them. A lot of Flathub Flatpaks are fundamentally not modifiable.
The Flathub default is painful for a lot of application experiences. For example, working with rich chat and trying to upload images or video clips is impossible by default. Frankly, it's incredibly asinine that someone thought that was reasonable. Er, what? Apps have a responsibility to not be completely stupid. Using the file chooser portal is not rocket science. xdg-desktop-portal has been around for long enough that we can reasonably expect applications to know how to do this. Maybe the app you're having trouble with should just not be packaged as a flatpak at all, if it's not ready for it. The need for Flatseal as a separate app is a huge flaw. That should be part of software center itself. This is a power user tool for software developers. End users should never need it. If you feel the need to use flatseal, that's a serious bug.
No. That way lays madness and abuse.
Neither iOS nor Android treat users as if they're too stupid to be able to manage permissions for applications right out of the gate. Neither Windows nor macOS do that either.
By not providing a way for users to control the security configuration right in the software center, you create an unworkable binary choice like Android had for years before they finally wised up and switched to granular permissions that users could manage.
If you want a successful experience, you need to provide people a smart and simple way to manage permissions for applications.
I don't see how these are "opaque software delivery methodologies". Everything is easily available publicly and uses OSTree to publish applications. Umm, then why does Flathub allow people pushing unverifiable blobs right into its OSTree remote? OBS Studio, Firefox, etc. are all done outside.
Umm, then why does Flathub allow people pushing unverifiable blobs right into its OSTree remote? OBS Studio, Firefox, etc. are all done outside.
Depending on the service that is being used, you find them in their CI pipeline. OBS Studio for example uses GitHub Actions. I do agree that this is more opaque than the standard Flathub's way, but you are definitely getting them from first-parties, so it has an advantage as well.
And a number of "transparent" Flatpaks are just repacked opaque packages with no trustable source and no support from the developer or the packager, which is even worse.
Not really, you can easily check what it downloads from the manifest or the build logs, which is quite similar to Fedora Flatpaks actually.
And there indeed is support. Of course, maintainers can only do so much if what they are maintaining is proprietary so there are technical limitations. I often contribute to Flatpak apps from Flathub and maintain some myself. I can tell that there is support.
Also, Flathub asks submitters to contact upstream developers and gain authorization from them before the application gets accepted. It used to not be like that, but it is now. At least it's a step in the right direction.
Yes, that's the nature of proprietary software. No one's disagreeing with you here and I wish everything was fundamentally modifiable by the end user. Regardless, this makes Flathub far more accessible than Fedora Flatpaks because many users rely on proprietary apps. At least they are relying on sandboxed environments which is still better than running packages from the system. There are always compromises to be done.
By not providing a way for users to control the security configuration right in the software center, you create an unworkable binary choice like Android had for years before they finally wised up and switched to granular permissions that users could manage. If you want a successful experience, you need to provide people a smart and simple way to manage permissions for applications.
That's a frontend issue, though. You can only do so much as a backend utility. Frontends should support these features like GNOME Software et al. This isn't a decision Flatpak takes.
And this literally applies with Fedora Flatpaks. Why should my browser have direct read access to my personal data like ssh and GPG keys? At that point, Fedora should include Flatseal, don't you think?
By the way, the user actually can manage permissions, but only with dynamic permissions; the same way Android does it. If you use GNOME, you go to Settings > Applications and you can manage them. Flatseal is a lot more powerful because it lets you manage static permissions, which are fundamentally insecure. There is no abuse here, but I do admit it's not perfect either.
And either way this is, again, a frontend issue. I would also argue that this is a distribution issue for not shipping Flatseal as well.
I don't see how these are "opaque software delivery methodologies".
There are good arguments on both sides, for example the calibre Flatpak on Flathub (which has --filesystem=host and --device=all) is not built from source. The manifest has the binaries for calibre and its dependencies downloaded from the archive (currently) at https://download.calibre-ebook.com/5.40.0/calibre-5.40.0-x86_64.txz.
--filesystem=host
--device=all
In that archive, you find complete binaries for Qt, including the entirety of Qt WebEngine. It contains image libraries, compression libraries, cryptographic libraries, SQLite, SSL, PDF, pretty much everything.
One of the libraries included is unrar, which is proprietary. So you can’t get calibre without proprietary software from Flathub. It doesn’t get labeled as proprietary in GNOME Software, though (hard problem to solve since there’s no metadata for licenses of dependencies).
In Fedora you get calibre built from source without proprietary dependencies, with system libraries also built from source, probably with Fedora’s default hardening flags, and you do have a way to know the licenses of dependencies. Not sandboxed though and there is no Fedora Flatpak for it.
Thanks for the information and that's a fair point.
By the way, the user actually can manage permissions, but only with dynamic permissions; the same way Android does it. If you use GNOME, you go to Settings > Applications and you can manage them. Flatseal is a lot more powerful because it lets you manage static permissions, which are fundamentally insecure. There is no abuse here, but I do admit it's not perfect either. And either way this is, again, a frontend issue. I would also argue that this is a distribution issue for not shipping Flatseal as well.
Again, Flatseal is not suitable for end users. If we wanted to support editing static permissions, it would be better to do that in gnome-control-center than to add a new app for it. But we don't, because these permissions are expected to be static and only software developers should need to mess with them. Asides from a few standard permissions, most static permissions are bugs to be fixed anyway. We should be using portals instead, but static permissions are pragmatic when no existing portal can do the job and we're too lazy to implement a new portal. They should be reduced and removed whenever possible.
If users have to edit static permissions, the app is broken and should be rebuilt with corrected permissions.
I certainly trust Flathub's applications more than Fedora's. It's much easier to contact developers or contribute to manifests.
I don't trust Flathub at all, because they don't want to register a non-profit organization. They can easily sell their business like FreeNode did last year.
Flathub relies on upstreams, not professional maintainers. Most of upstream developers don't know how to package software properly. They bundle lots of libraries, don't use hardening flags, etc.
Due to the bundling of a large number of libraries, some applications have critical vulnerabilities with assigned CVE numbers: CVE-2020-12284, CVE-2019-17498, CVE-2018-11235, CVE-2018-17456, CVE-2017-9780.
I trust apps that are provided by first parties like OBS Studio and Firefox.
All packages must be built completely from sources on trusted infrastructure to be trustworthy.
"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
--filesystem={home,host}
That means they have no isolation at all and can do everything they want including changing permissions/etc.
I asked Flathub's admin. His answers:
<img alt="1" src="https://i.imgur.com/BbuEXGo.png" /> <img alt="2" src="https://i.imgur.com/33YgeYn.png" />
Matrix links: 1, 2.
Flathub is a trademark of the GNOME Foundation.
"Sandboxing" is the biggest lie. A lot of apps have --filesystem={home,host} in manifests:
Good apps don't do this. Apps that do should be displayed as insecure in GNOME Software. We can get stricter over time: I'd like to see these apps filtered out altogether. If your app needs this level of access, you can use distro packages rather than attempting to shoehorn it into a flatpak, or pay a discoverability penalty.
They bundle lots of libraries, don't use hardening flags, etc.
I think hardening flags are automatically injected somehow, but I'm not certain. We'd need to see build logs to be sure. Fun fact: the freedesktop-sdk and GNOME hardening flags are based on Fedora's.
Infra doesn't belongs to the GNOME Foundation. The GNOME Foundation doesn't control Flathub. It has own admins. They are not even elected.
I asked multiple times on their Matrix channel. They ignore the question about creating a non-profit organization.
I think hardening flags are automatically injected somehow, but I'm not certain.
Previously Firefox flatpak had ASLR and other hardening disabled (maybe it is disabled now, someone need to verify). All other repackaged from deb/tgz also don't use these flags.
Good apps don't do this.
159 apps do this.
We can get stricter over time
Apps not built from sources should be displayed as insecure too.
To be trustworthy, Flathub should do the following:
--filesystem={home,system}
Bart works for the GNOME Foundation. I'm not sure who the other Flathub admin is.
I assure you, GNOME owns Flathub. Staff are not elected, but GNOME Foundation board members are.
I agree this is unaccepted. I asked for a status update on this earlier in this thread.
Good apps don't do this. 159 apps do this.
They're bad apps.
We can get stricter over time Apps not built from sources should be displayed as insecure too.
I agree.
I assure you, GNOME owns Flathub.
Where I can see any legal documents with proofs?
Staff are not elected, but GNOME Foundation board members are.
Why not?
Or just lazy upstream developers. I think most packages can be easily fixed.
Hi as a "Flathub person" - I'm following along here and lurking in the Workstation Matrix chat, and happy to attend meetings (as timezones permit) to help navigate the multiple topics that are in play here.
I am sympathetic to concerns that because of less strict standards for how builds are configured, dependencies selected, etc an arbitrary Flatpak from Flathub might not be as well-packaged as the Fedora equivalent, particularly if the application itself is not well-ported to run in Flatpak sandbox and requires various workarounds and sandbox escapes.
However, this overlooks the key distinction which is that Flathub's primary purpose is not to merely serve as "another distro" where third party software is rebuild/reconfigured/bundled by the community in different ways, but to place these options in the hands of the software developers themselves who are then able to make these decisions holistically together with the implementation decisions they make in the software itself, and establish a deployment and feedback loop directly with the user.
In these cases, I would be less unquestionably confident that Fedora could offer a more timely, better built or more trusted version than the software developer themselves. (I'm sure there are some counterexamples of user-hostile developers, but in this case I would argue that downstream maintainers who are trying to override their decisions are effectively maintaining a fork rather than merely facilitating distribution.)
We are currently working on a project with contractors to add a number of features to Flathub, including donations and payments for software, but also to establish a process to verify when the Flatpak is controlled by / uploaded by the original software author. We're planning to publish this in the metadata as well as provide a filtered repository for people who only want to see/consider such verified apps.
The GNOME Foundation acts as a fiscal sponsor for Flathub and is supporting with staffing, legal support and some other operating costs, but as set out at https://discourse.flathub.org/t/kickstarting-flathub-governance/2054 we are working on a process to improve the transparency and participation in project governance, and ensure the right legal structures are in place to allow both our transaction needs (donations/payments/etc) and fundraising for future sustainability.
As @catanzaro says, over time and with growth/funding we hope to set up both automated and social processes which will better indicate whether apps are sufficiently confined or not, such as publishing what are acceptable permissions, what are dangerous, indicating them to users, setting up goals across the platform to replace old permissions with new APIs, etc.
Again, Flatseal is not suitable for end users. If we wanted to support editing static permissions, it would be better to do that in gnome-control-center than to add a new app for it. But we don't, because these permissions are expected to be static and only software developers should need to mess with them. Asides from a few standard permissions, most static permissions are bugs to be fixed anyway. We should be using portals instead, but static permissions are pragmatic when no existing portal can do the job and we're too lazy to implement a new portal. They should be reduced and removed whenever possible. If users have to edit static permissions, the app is broken and should be rebuilt with corrected permissions.
I know and I totally agree with you. I was just mentioning that some of the issues others have raised about Flathub are analogous to Fedora Flatpaks.
Good point, I haven't thought of that. However, there is also this other trust as in official support.
At the end of the day, an external contributor can contribute too.
"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 That means they have no isolation at all and can do everything they want including changing permissions/etc.
Filesystem permissions aren't the only things that matter. You have to take D-Bus access into account too, and giving it host permissions still restricts these apps from accessing /proc or other Flatpak apps' data (in ~/.var/app). Although, on the other hand, you are right because these programs can write in shell files to override permissions. I wouldn't say it's unsandboxed, but a huge security hole at that.
/proc
~/.var/app
Please see this issue where we're trying to address this. Ultimately, flatpak provides a lot of knobs that affect how safe the resulting app can be. It's up to UIs like GNOME Software to decide how (or whether) to present these.
In general, I would say that any app with custom D-Bus permissions should be presented as insecure.
Also if we're allowed to preinstall unfiltered Flathub, than we can do the same for the RPM Fusion repository. Users will have fully featured ffmpeg with all codecs support. We are still not able to do this. Sorry.
Why we can add unfiltered Flathub (it contains both patent-encumbered and proprietary software) and we can't add RPM Fusion at the same time?
It's a very good question. Sadly, I believe Fedora Legal does not want us to answer it. I know this is quite frustrating. :/ Speculation: perhaps they fear that advertising their reasoning for this choice could impact our liability.
Suffice to say they are trying to allow as much as possible.
Was this changed applied for F36? Flathub is being shown as "Fedora Flathub Selection":
<img alt="Screenshot_from_2022-05-12_01-26-09.png" src="/fedora-workstation/issue/raw/files/acb993407978dff954acb36181eeb4327c2aa37852247a1394176b7367f2dfd5-Screenshot_from_2022-05-12_01-26-09.png" />
Fedora Flathub Selection was already showing by default in the software repositories options at the "Fedora Third-Party" section. However, after adding the Flathub repo, Fedora Flathub Selection moved to the top and got placed at "Applications (Flatpak)" and it didn't get enabled by default, even after rebooting.
No, we just learned about this. Hopefully we'll be able to do this for F37.
Was this changed applied for F36? Flathub is being shown as "Fedora Flathub Selection": No, we just learned about this. Hopefully we'll be able to do this for F37.
Understood. Seems to be an issue with flatpak: https://bugzilla.redhat.com/show_bug.cgi?id=2084411
Action: Matthias to prepare a change proposal to enable Flathub when third-party repos are enabled. We will change the filter from an allowlist to a denylist. The denylist will be empty: we'll just keep it around in case we need it unexpectedly in the future.
Metadata Update from @catanzaro: - Issue assigned to mclasen - Issue tagged with: pending-action
First GNOME Software need to be patched to prefer RPMs over Flatpaks for non-ostree Fedora variants, because it will replace Fedora packages with Flatpaks.
The Workstation WG discussed this at today's meeting, and we have consensus to prefer flatpaks. I believe default order of precedence will be: Fedora flatpak > Flathub flatpak > Fedora RPM. Users who wish to install RPMs can still choose to do so via GNOME Software, it just won't be the default option. (Users can change this if desired, #187). We encourage Fedora packagers to make more applications available as Fedora flatpaks if desired.
It also doesn't make much sense to prefer RPMs over Flatpaks when we are going to replace the preinstalled apps with Flatpaks, #269.
I expect flathub applications to have outdated dependencies and more security vulnerabilities, but this trade-off is OK because the possibility to have a strong sandbox is much more important. Hopefully in the future, flathub will become more stringent about limiting apps with sandbox holes, but in the meantime at least the flathub apps have a good chance to be sandboxed, while Fedora RPMs are almost never sandboxed.
Some Fedora Flatpaks are outdated. For example, Firefox from Fedora Flatpaks is at version 99.0.1, while the RPM version is at 100.0.2. Will this get improved in the future?
That's up to maintainers, not up to the Working Group. I will say that it is disappointing to see outdated Firefox, though.
We encourage Fedora packagers to make more applications available as Fedora flatpaks if desired.
I personally encourage to stop pushing outdated and/or broken apps:
<img alt="Untitled.png" src="/fedora-workstation/issue/raw/files/745a7d2999b031d98e380d3747d250d0036efca9163707ba0686c745a38d0e0c-Untitled.png" />
Edit: Fixed, https://pagure.io/fedora-workstation/issue/315.
The Workstation WG discussed this at today's meeting, and we have consensus to prefer flatpaks.
The WG SIG wants to kill all RPMs in favor of a 3rd party repository, right?
I believe default order of precedence will be: Fedora flatpak > Flathub flatpak > Fedora RPM.
I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM" for Silverblue/Kinoite will be better.
it just won't be the default option. (Users can change this if desired, #187).
Most users always use the defaults. This means they will always install Flatpaks.
Fedora Flatpaks are almost dead: 29233 vs. 104 Bodhi updates: https://bodhi.fedoraproject.org/releases/
I expect flathub applications to have outdated dependencies and more security vulnerabilities, but this trade-off is OK because the possibility to have a strong sandbox is much more important.
https://ludocode.com/blog/flatpak-is-not-the-future
I wasn't there today because I wound up being too busy to attend, but for what it's worth, I want Fedora sources to be preferred in all circumstances over non-Fedora ones. That means if we prefer Flatpaks, then it should be "Fedora Flatpak > Fedora RPM > non-Fedora Flatpak".
Yeah I know you do Neal, but you're sorely underestimating the security benefit of the flatpak sandbox, which RPM apps just cannot compete with (with a few rare exceptions, notably web browsers). Let's look at RPMs as a great technology for composing containers and images, but not the primary way we distribute apps in the future.
Anyway, switching to flatpak-first is a good transition path towards Silverblue, without actually becoming Silverblue.
I think you're sorely overestimating how much Flatpak's sandbox actually helps from a user protection point of view. Flatpaks don't protect user data, they're not designed to do that. And that's the thing users actually care about.
Consider the Secrets password manager. The Flatpak on Flathub doesn’t have --share=network nor does it have any permissions that would allow it to break out of the sandbox without a zero-day exploit.
--share=network
This has the following consequence: if Secrets or one of its many Python dependencies is compromised (for example in some supply-chain attack), it cannot exfiltrate your passwords (because it has no Internet access).
Other apps, if they are poorly sandboxed, may be able to, but the attack is more complicated then because they aren’t your password manager and don’t have directly access to your unencrypted passwords in their memory.
The sandbox in this case is a huge improvement in protection of user data. Arguably the most important of all user data, for people who use a password manager.
I care about my personal data, that's precisely why I use flatpak. Remember that time steam had a bug that wiped the entire disk and it wasn't just once, but at least two or three times. Remember those multiple times that npm had compromised packages? Or how installing wine with DNF pollutes the entire home?
I do understand why it is desirable for the Fedora Project to use their own Flatpak repository over Flathub and it does makes a lot of sense, except whenever I try one Flatpak in the Fedora repository I find problems that are not present in the Flathub build. The Firefox build in the Fedora repository is completely unusable, the default Adwaita theme is broken, outdated versions, and so on... I just cannot bring myself to ever recommend the Flatpaks in the Fedora repo.
RPM is the main packaging format for Fedora. Everyone must follow Fedora guidelines.
Yeah I know you do Neal, but you're sorely underestimating the security benefit of the flatpak sandbox, which RPM apps just cannot compete with (with a few rare exceptions, notably web browsers).
Let's let users make choices, not choose for them.
Remember that time steam had a bug that wiped the entire disk and it wasn't just once, but at least two or three times.
Can you post links to bug reports? I can't remember it.
Or how installing wine with DNF pollutes the entire home?
And Flatpak will pollute ~/.var/***/.wine.
~/.var/***/.wine
I do understand why it is desirable for the Fedora Project to use their own Flatpak repository over Flathub and it does makes a lot of sense, except whenever I try one Flatpak in the Fedora repository I find problems that are not present in the Flathub build.
Firefox from Flathub doesn't built from sources and has disabled ASLR.
Excuse me, what?
In the Flatpak docs:
One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment. [...]
Also, XDG portals literally exist to make flatpaks run conveniently without punching too many holes in the sandbox.
So? This is infinitely better than polluting $HOME. This is one of the many reasons why many of us choose Flatpak.
$HOME
And again, I highly suggest to not push Fedora Flatpaks for the time being. It's inherently broken and doesn't integrate well in the desktop. I posted an image recently to show its current: https://pagure.io/fedora-workstation/issue/300#comment-799982. I would be completely okay to let Fedora Flatpaks be the default remote when it matures, but right now, Flathub is far more practical.
Many people I've met online who had problems with Flatpak were caused by Fedora Flatpaks. The only solution was to use Flathub and to avoid Fedora Flatpaks.
That is not true. A sandboxed app that gets compromised has no access to the user's home directory and the attacker can only see files explicitly granted access via a portal (documents portal, file chooser portal, OpenURI portal). A compromised Fedora RPM, in contrast, can just upload your entire home directory to the attacker. This is the entire point of having the sandbox: it wouldn't be useful otherwise.
And again, I highly suggest to not push Fedora Flatpaks for the time being. It's inherently broken and doesn't integrate well in the desktop. I posted an image recently to show its current: https://pagure.io/fedora-workstation/issue/300#comment-799982. I would be completely okay to let Fedora Flatpaks be the default remote when it matures, but right now, Flathub is far more practical. Many people I've met online who had problems with Flatpak were caused by Fedora Flatpaks. The only solution was to use Flathub and to avoid Fedora Flatpaks.
OK, can you open another issue (in this issue tracker) for this please? Fedora Flatpaks have been preferred over RPMs for several years now, and backtracking on that would be a big change. I was not aware of these complaints.
Done https://pagure.io/fedora-workstation/issue/315. I'm surprised that no one reported it. It's been a thing for a long time.
Edit: fixed. It was caused by a custom theme.
Impractical.
Users choose a platform based primarily on trust. Fedora the product is the culmination of choices Fedora the community make. This includes making a choice on behalf of users, such as default behaviors. We can't have a "none" default, and require every user to expressly choose "RPM-centric" vs "Flatpak-centric". That would be a roll of the dice.
I think it's reasonable for Fedora variants, the output from SIGs, to make this choice.
As for my super-ultra-selfish position, I really don't want to think about this topic that much. I want to trust Fedora to make these kinds of security vs usability tradeoffs for me. Ergo, the community has a ton of choice. Individual users shouldn't be burdened with choice most of the time.
Users choose a platform based primarily on trust. Fedora the product is the culmination of choices Fedora the community make.
I can trust Fedora and I can't trust Flathub, because a lot of popular packages on Flathub are just repackages of third-party DEBs (Signal, Element, Blender, etc.) or even uploaded as an ostree blob (OBS Studio, Firefox).
We can't have a "none" default, and require every user to expressly choose "RPM-centric" vs "Flatpak-centric". That would be a roll of the dice.
Gnome software should explicitly ask the user to select a package source before starting installation.
Users choose a platform based primarily on trust. Fedora the product is the culmination of choices Fedora the community make. I can trust Fedora and I can't trust Flathub, because a lot of popular packages on Flathub are just repackages of third-party DEBs (Signal, Element, Blender, etc.) or even uploaded as an ostree blob (OBS Studio, Firefox). We can't have a "none" default, and require every user to expressly choose "RPM-centric" vs "Flatpak-centric". That would be a roll of the dice. Gnome software should explicitly ask the user to select a package source before starting installation.
This is something that could be set the first time you launch GNOME Software. The downside is that it adds more complexity; the challenge is that users may not to know which one to pick.
It might be a good idea to default to Fedora's Flatpak/RPM (when applicable) and leave Flathub as an optional choice in the list.
Change proposal: https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
For the record: Neal has indicated opposition to this change. The rest of the WG seems to be supportive. (Neal was not present at the meeting when we approved the change by consensus.)
We should talk over the specifics of the proposal and potentially have a vote if there isn't consensus.
Metadata Update from @aday: - Issue untagged with: pending-action - Issue tagged with: meeting
As an upstream developer, I would be very happy to make it easier for Totem's Flathub Flatpak to be easier to install, as it provides loads of features and integration that the Fedora RPM can't for various reasons.
Unfortunately, we can't really ship Fedora Workstation without totem, but it would be great to find a way to automatically "upgrade" Fedora RPMs to their Flathub variants for select applications.
I discussed this 3 years ago on the fedora desktop list (and got yelled at): https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/LJKQWKTPRCEOBOLVBZ45TQO5POUCGROL/#C4ZDTB4QP4Z4OCFZW3KUWPQ2E43V3TSZ
But we hit the technical limitation that we should have a movie player in the base install.
Metadata Update from @aday: - Issue set to the milestone: Fedora 37
In terms of format, I don't have a strong opinion, there's tradeoffs. flatpaks are still harder to troubleshoot from the user perspective, although I don't often have problems so I don't have any examples. flatpaks may be incrementally safer in some cases.
But I'm scratching my head how bad it is to make it incrementally easier for users to install and run software contrary to their expectations. i.e. by enabling 3rd party repos with a single click, this also enables flathub repo, and if flatpaks are favored over RPM is it more likely users get exposed to questionable programs (data mining, pirated, malicious, etc)? Whatever we decide is based on what we know about flathub today, but what if that changes? How would we react, and how quickly could we react?
flatpaks may be incrementally safer in some cases.
This is major understatement. Flatpaks use a strong sandbox that all but completely isolates the application from the host system. i.e. flatpaks are very safe (unless the app disables these protections, which GNOME Software detects and displays as a negative). Whereas application packaged as RPMs have no sandbox at all.
Remember the vast majority of Linux applications are written in unsafe languages, where very common mistakes can result in total compromise. Analogy: using an unsafe language is like skyscraper construction where all the workers are drunk. People are going to fall off a lot. The sandbox is a safety harness which mitigates the badness when this happens. A sandbox failure is possible but very rare.
Flathub isn't that bad. In the unlikely event that it becomes that bad in the future, and we decide we need to disable the flathub repo, our reaction time would be a little over two weeks, since it takes a couple days to prepare a Fedora update, and GNOME Software will wait two weeks to check for updates.
We discussed this issue during yesterday's WG meeting. Main points from that:
It's clear from the working group's discussions on this topic that there are differing opinions, and we might not be able to get consensus on everything here. While consensus is preferable, we also have to accept that it isn't always possible. In these cases, I think that it's important for everyone to have their point of view heard, in as factual a manner as possible, and for those points of view not to be dismissed out of hand.
Going back to @otaylor's questions about this proposal, it seems that the current plan is:
(1-4 all affect GNOME Software only.)
If anyone from the working group believes that any of these choices are incorrect, it would be helpful if they could provide a short summary of why it is that they think this.
No special handling of IDEs...? (Say, preferring an RPM over a Flatpak for some apps.)
If we aren't going to have special handling of IDEs, then that concerns me. I wouldn't want people installing the Flathub version of VS Code and being surprised when it doesn't work as well as it should. I also wonder where this leaves #283, as well as our existing PyCharm 3rd party repo.
Investigate a "preferred vendor" configuration option ...
Being completely honest, I don't really get this. It seems like the kind of feature that people who work on distros care about, and everyone else is going to ignore. In my observations of users, they just want to install the app and have it work well, without having to make choices about where it's coming from.
I highly doubt that's true. Users care about where apps are coming from. We already give them the option to choose where to install from, but it's easy to miss this, and users will appreciate having the ability to choose what source gets preferred by default.
Absolutely, however this isn't something (newer) users typically understand when they encounter issues. Many GUI applications packaged by distributions give the impression that they are maintained by upstream because the description doesn't say otherwise, and/or distributions make it very difficult to contact downstream. Fedora at least has https://packages.fedoraproject.org, but many users are unaware of this website, and frankly contacting upstream directly is a lot easier to engage and track, in my opinion.
Being completely honest, I don't really get this. It seems like the kind of feature that people who work on distros care about, and everyone else is going to ignore. In my observations of users, they just want to install the app and have it work well, without having to make choices about where it's coming from. Absolutely, however this isn't something (newer) users typically understand when they encounter issues. Many GUI applications packaged by distributions give the impression that they are maintained by upstream because the description doesn't say otherwise, and/or distributions make it very difficult to contact downstream. Fedora at least has https://packages.fedoraproject.org, but many users are unaware of this website, and frankly contacting upstream directly is a lot easier to engage and track, in my opinion.
I hope I'm not out of line commenting on this issue, but would it make sense to have the Fedora logo on the RPM and Flatpaks provided by Fedora and the Flathub logo on the others? This may make it a bit more visible to the user where the application is distributed from.
Edit: I realize that many users won't even know what a Flatpak is. Would "Third party source" or "Third party" be a more sensible label?
<img alt="unknown.png" src="/fedora-workstation/issue/raw/files/3bb3652bc858837428dfaf4499175f89969ff5d54ac64b1b5eb0c43196b392de-unknown.png" />
Everybody is allowed to comment here. ;)
Another consideration of having Flathub more easily accessible is that it can make it possible to upgrade software beyond what was available/possible in the original version of the distribution.
For example, shipping updated core GNOME applications on the older "-1" version of Fedora without dragging the whole of the new GNOME into that older distribution.
would it make sense to have the Fedora logo on the RPM and Flatpaks provided by Fedora and the Flathub logo on the others? This may make it a bit more visible to the user where the application is distributed from.
There are plans to make the source and format of each app more visible prior to installation, and those changes will hopefully be implemented in time for Fedora 37. See:
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1754
Those designs use an icon to indicate the format and a string to indicate the source. It's not exactly what you're asking for, but it's close.
would it make sense to have the Fedora logo on the RPM and Flatpaks provided by Fedora and the Flathub logo on the others? This may make it a bit more visible to the user where the application is distributed from. There are plans to make the source and format of each app more visible prior to installation, and those changes will hopefully be implemented in time for Fedora 37. See: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1754 Those designs use an icon to indicate the format and a string to indicate the source. It's not exactly what you're asking for, but it's close.
The designs look great, is there any abbreviated form of Flatpak such as eg. FPK? I just wonder if names such as Flathub/Flatpak and RPM will seem foreign to everyday users. Perhaps there could be a link to the respective technologies used in the "About" section?
You mention that this will be more visible prior to installation, I look forward to seeing what is planned :)
Metadata Update from @aday: - Issue untagged with: meeting
Investigate a "preferred vendor" configuration option ... Being completely honest, I don't really get this. It seems like the kind of feature that people who work on distros care about, and everyone else is going to ignore. In my observations of users, they just want to install the app and have it work well, without having to make choices about where it's coming from.
Preferred vendors are useful for distributions and corporate systems administrators. For distributions, it ensures that content that we provide are visible and used by default over third parties. For companies, there are corporate policy preferences that they'd like to manage en masse. For example, preferring an RPM from a vendor they're paying rather than a community repackage, or something of that nature.
FESCo has rejected our change proposal with a vote of (+0, 4, -4), meaning no FESCo members supported the change. I think it would probably have been approved if we had preferred Fedora RPMs to Flathub rather than vice-versa, and we've been encouraged to submit the proposal again with that changed. This would require changes in GNOME Software.
It may be time to seriously consider no longer displaying RPM-based applications in GNOME Software at all, unless they are already installed, but to do that we would have to first figure out #125.
Historical note: I believe this is the first time FESCo has blocked a change approved by Workstation WG.
Here is what Milan told me about repo sorting:
I recall Allan Day did have an idea of a drag&drop reorder in the Repositories dialog, which would mean to be able to reorder groups and in them the repos, but it did not materialize anywhere. I cannot find a corresponding bug for it at the moment, maybe it has got lost or it had been just mentioned in the rewrite of the Repositories dialog bug). The current "sorting" option, the hidden one in the GSettings, is only about the format, not about actual repos. Making it work would be non-trivial. Another problem is that Philip Withnall is going for a longer vacation (few months) soon, thus it'll be harder to get any review for a merge request in the gnome-software (there is a deal with two folks doing them while Philip is gone). That being said, I'm not sure whether it could be done for the 43, the drag&drop part might be the a bigger problem (for me), than the "select app from certain repo before other repo, when more variants of the same app are available with the same version" - offering from a repo a version lower than available in another repo sounds wrong).
I recall Allan Day did have an idea of a drag&drop reorder in the Repositories dialog, which would mean to be able to reorder groups and in them the repos, but it did not materialize anywhere. I cannot find a corresponding bug for it at the moment, maybe it has got lost or it had been just mentioned in the rewrite of the Repositories dialog bug).
The current "sorting" option, the hidden one in the GSettings, is only about the format, not about actual repos.
Making it work would be non-trivial. Another problem is that Philip Withnall is going for a longer vacation (few months) soon, thus it'll be harder to get any review for a merge request in the gnome-software (there is a deal with two folks doing them while Philip is gone). That being said, I'm not sure whether it could be done for the 43, the drag&drop part might be the a bigger problem (for me), than the "select app from certain repo before other repo, when more variants of the same app are available with the same version" - offering from a repo a version lower than available in another repo sounds wrong).
Let's focus on GNOME 44 (Fedora 38) timeframe, not GNOME 43. There is not enough time for Milan to develop such a major change in the month remaining before code freeze.
Prefer Flathub Flatpaks over Fedora RPMs
Just by having the 3rd party repos option enabled, suddenly even software in Fedora repos will no longer come from Fedora. That is not obvious. Users who have 3rd party repo enabled get an upstream Firefox flatpaked by Mozilla via flathub. Users who have 3rd party repo disable (the current default) get a Fedora packaged RPM of Firefox, which has rather different compile time options and settings defaults.
We're planning on having QA test both configurations since they are both equally valid? Which one is the default behavior? If the Firefox flatpak from flathub is the default installation, then that suggests flathub is enabled by default, rather than tied to the 3rd party repo preference? And how do we handle release blocking bugs if they're flathub blockers?
We've already discussed that bug reporting is a problem, whether to report in RHBZ or upstream. The flathub flatpak being primary might help solve that in that ostensibly it's upstream handling both the bugs in the code and the packaging, rather than the distribution.
But is this going to be all very confusing for users? Are we in effect talking about two different products or outputs from the Workstation working group? I'm not sure I'd give this sort of "Autobots! Transform!" switch to users. I don't know that they can or want to understand it. So I wonder if there should be separate products, but I also don't know what to call them that conveys differentiation in simple terms.
@mclasen has updated the change proposal to target F38 rather than F37:
https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
That will give us time to work on the proposal some more and hopefully come up with something that is more acceptable.
Metadata Update from @aday: - Issue set to the milestone: Fedora 38 (was: Fedora 37)
It would be really useful to have data on the current overlap between the apps that are in Fedora RPM, Fedora Flatpak and Flathub. It would be great if someone could provide that!
I developed a simple Python3 script and listed all packages on F36 with: - Flathub packages: flatpak remote-ls | grep flathub - Fedora flatpak packages: flatpak remote-ls | grep fedora - Fedora RPM packages: dnf list | grep -e fedora -e updates -v rpmfusion -v 'copr:copr'
Total number of packages for each: - Flathub packages: 3128 - Fedora Flatpak packages: 92 - Fedora RPM packages: 69214 (orphaned/unmaintained packages were not counted)
Comparisons: - Flathub X Fedora Flatpak: 75 - Flathub X Fedora RPM: 700 ~ 1200
Why is the Flathub X Fedora RPM approximated? 1. The naming of the packages can be slightly different, which makes it harder to grep/search a package in the pandas data frame 1.1 To mitigate this problem, I used to search for substrings, which may not be precise. 2. Some RPM packages correspond to multiple Flathub packages: for example, the Yaru theme RPM package unfolds into 76 Flathub packages. 2.2 Moreover then themes, Flathub also counts extensions and plugins that may not have an RPM correspondent or, sometimes, are inside the base package.
Most of the packages that are not in Fedora RPM, but it is on Flathub are proprietary software (electron-based software, NVIDIA software, Valve software, etc) and some unlicensed games.
I don't know if anyone has a better way to get the datasets for analysis.
Note that since Flatpaks use AppStream metainfo names, those names can be queried by looking for metainfo() Provides in packages if they were installed properly.
metainfo()
Thanks @mairacanal ! This is great. I think that ideally we'd only include apps in the analysis, so would need to filter out packages that aren't desktop apps.
Here is a gnome-software change proposal to be able to define preferred packaging format together with the origin name: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1511
With that applied, the Workstation installation can set for example this:
[ 'rpm', 'flatpak:fedora', 'flatpak' ]
while the Silverblue installation can set for example this:
[ 'flatpak:fedora', 'flatpak', 'rpm' ]
into the existing org.gnome.software packaging-format-preference GSettings key.
org.gnome.software
packaging-format-preference
Metadata Update from @catanzaro: - Issue tagged with: meeting
Metadata Update from @catanzaro: - Issue untagged with: meeting
Not sure if you still intend to propose this for F38, but just a reminder of dates:
Proposal submission deadline (System Wide Changes): 2022-12-27 Proposal submission deadline (Self Contained Changes): 2023-01-17
It's marked as a System Wide Change, but perhaps you can still squeeze it in.
Metadata Update from @catanzaro: - Issue tagged with: pending-action
I think that this change happened for F38 - closing.
Metadata Update from @aday: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.